RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

>> Guile doesn’t care about whether it is a cache or not, as long as it has the 
>> .go, the timestamps are ok, and (IIRC) corresponding .scm exists.
>I wonder if you have tested the given example. Guile doesn't load .go as the 
>dependency, but .scm. 
I didn’t test it, because:
• I know how you described it in the example, is how it works (except for the 
‘no way to load deps from .go without cache’ falsehood, and except for the 
misnaming of the .go which I didn’t notice at first).
• As I mentioned in the beginning, I don’t have a Guile setup currently.
Also, post-hoc: your example is wrong, in the sense that you gave the compiled 
module the wrong name! You should name it ./obj/mod/X.go, not 
./obj/mod/X.scm.go. If it then still not loads the .go, that’s a bug and a 
regression.
>> You missed ‘-C’ (load-compiled-path)
>I didn't miss load-compiled-path here, I think you confused with -c. -C obj 
>specified the current load compiled path to "./obj".
No. I don’t care at all about lowercase ‘-c’ here. I mentioned ‘-C’ precisely 
_because_ it augments the load compiled path. At first I didn’t notice the ‘-C’ 
because of the rest of the message implied you didn’t set it.
>- the deps have to be loaded from the scm path specified by -L. IIRC there is 
>no way to load deps from .go, unless you provide a manual caching.
Namely, this. “-C insert-directory-here” is _the_ way to load dependencies from 
.go (at least, dependencies in form of module imports, I’m not too sure about 
how loading the initial file (as .scm) works) and it doesn’t need to be a 
cache. Yet, simultaneously you say there is no way (without caches), _and_ you 
actually are using that way (“-C obj”).
Best regards,
Maxime Devos