Incremental compilation

[Panicz Maciej Godek]

I also noticed that if I don't provide "." in kawa.import.path, I get the
following warnings/errors (even though the modules are located in ./src
directory, or are intended to be in ./build/cache)


/data/data/com.termux/files/home/grasp/src/language/define-type.scm:3:9:
unknown library (utils conversions)
/data/data/com.termux/files/home/grasp/src/language/define-type.scm:7:9:
unknown library (language define-property)

 /data/data/com.termux/files/home/grasp/src/language/define-type.scm:8:9:
unknown library (language match)
/data/data/com.termux/files/home/grasp/src/language/define-type.scm:9:9:
unknown library (language fundamental)

 /data/data/com.termux/files/home/grasp/src/language/define-type.scm:262:1:
evaluating syntax transformer 'type-definition' threw
/data/data/com.termux/files/home/grasp/src/language/define-type.scm:191:25:
unbound location: keyword->symbol
    gnu.expr.ReferenceExp.apply(ReferenceExp.java:163)
    gnu.expr.Expression.applyMethodExpression(Expression.java:41)
    jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
...

wt., 4 cze 2024, 15:39 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

>
>
>
>
> wt., 4 cze 2024, 05:37 użytkownik Panicz Maciej Godek <
> godek.maciek@gmail.com> napisał:
>
>> ;
>>
>> pon., 3 cze 2024, 15:00 użytkownik Panicz Maciej Godek <
>> godek.maciek@gmail.com> napisał:
>>
>>> After I had to recompile GRASP for a number of times in a row, I decided
>>> to try to implement a build system that would only recompile the modules
>>> that either changed, or depend on modules that changed.
>>>
>>> Until now, I had three build scripts, for each version of GRASP (one for
>>> Android, one for desktop and one for terminal). They all relied on a
>>> dependency analyzer that I wrote in order to spot circular dependencies
>>> between modules (in my experience, Kawa didn't provide valuable information
>>> when facing circular dependencies; it was just failing in some weird ways).
>>> But since I already had the list of required modules, I could simply pass
>>> it to Kawa via command line, and apparently Kawa figured everything out by
>>> itself.
>>>
>>> But for the script, I'm trying to use the "compile-module" procedure
>>> (essentially because the new build script is written entirely in Kawa). It
>>> produces zip/jar archives instead of .class files, but I can just unzip
>>> them after build.
>>>
>>> The source files are all located in the "src" directory. I would like
>>> the .class files to be located in the "build/cache" directory, with the
>>> directory structure mimicking the one from the "src" directory. And for
>>> some modules this is indeed the case. But other modules are built in the
>>> "build/cache/src" directory (i.e. after the build, the files contained in
>>> the resulting .zip file are all placed in the "src" directory). I suspect
>>> that the ones without the "src" prefix also happen to be the dependencies
>>> of the shell script.
>>>
>>> In either case, I am able to build the dependencies in the proper order.
>>>
>>> I run the script with the following shell preamble:
>>>
>>> #!/bin/sh
>>> #|
>>> mkdir -p build/cache
>>>
>>> JARS=`ls libs/*.jar | tr '\n' ':' | sed 's/:$//'`
>>>
>>> exec java -cp "$JARS:build/cache" kawa.repl \
>>>   -Dkawa.import.path="|:src:.:build/cache" \
>>>   -f "$0"
>>> |#
>>>
>>> where the libs folder contains kawa.jar and a few other dependencies.
>>>
>>> However, when I build the modules, at some point I get the following
>>> exception:
>>>
>>> gnu.text.SyntaxException: src/editor/interfaces/elements.scm:17:9:
>>> unknown library (utils print)
>>> src/editor/interfaces/elements.scm:18:9: unknown library (utils
>>> string-building)
>>> src/editor/interfaces/elements.scm:22:9: unknown library (editor
>>> interfaces painting)
>>>
>>>         at kawa.lib.system.compileFile(system.scm:92)
>>>         at atInteractiveLevel$Mn51.run(build.scm:313)
>>>         at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:290)
>>>         at kawa.Shell.run(Shell.java:300)
>>>         at kawa.Shell.runFile(Shell.java:562)
>>>         at kawa.Shell.runFileOrClass(Shell.java:485)
>>>         at kawa.repl.processArgs(repl.java:298)
>>>         at kawa.repl.main(repl.java:830)
>>>
>>> I know that, at this point, the files utils/print.class,
>>> utils/string$Mnbuilding.class and editor/interfaces/painting.class are
>>> already present in the build system, and build/cache should be in both
>>> jvm's class path and kawa.import.path. How do I convince Kawa to look in
>>> there for the modules?
>>>
>>> I also have another problem: when these few classes already exist, and I
>>> try to re-run the script, it fails to start with the following message:
>>>
>>> src/language/define-syntax-rule.scm:1:15: unbound location: language
>>>         at gnu.mapping.DynamicLocation.get(DynamicLocation.java:36)
>>>              at
>>> language.define$Mnsyntax$Mnrule.run(define-syntax-rule.scm:1)
>>>         at gnu.expr.ModuleBody.run(ModuleBody.java:51)
>>>         at gnu.expr.ModuleBody.run(ModuleBody.java:35)
>>>         at atInteractiveLevel$Mn3.run(build.scm:14)
>>>              at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:290)
>>>                at kawa.Shell.run(Shell.java:300)
>>>         at kawa.Shell.runFile(Shell.java:562)
>>>         at kawa.Shell.runFileOrClass(Shell.java:485)
>>>         at kawa.repl.processArgs(repl.java:298)
>>>         at kawa.repl.main(repl.java:830)
>>>
>>
>> Maybe I should also mention that the only place in which the symbol
>> 'language' appears is in the (module-name (language define-syntax-rule))
>> clause
>>
>
> Also, the build script contains (import (language define-syntax-rule)) as
> its first external export, and I'd think it's weird that it looks in the
> src directory, even though the compiled define$Mnsyntax$Mnruke.class file
> is present in the build/cache/language directory
>