RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions <guile-user@gnu.org>]

>> 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