RE: Running Compiled Guile Objects

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

➢ IMHO, the manually .go loading will cause more issues.
➢ First, here's a fact: manually loading will not bypass the intrinsic .go caching. Only the first .go will, and the rest of the deps chain will still be managed by the intrinsic caching. [snip]
[snip: module (a) (a.scm / a.go) uses module (b) (b.scm / b.go))
I don’t see ‘more issues’ here. The (non-)issue you mention exists regardless of whether module a is loaded as ‘a.scm’ or as ‘b.go’. Also autocompilation causes its own issues, if it requires things in the environment during compilation that aren’t available at time or use (e.g. a C pre-processor in case a library using macros from a FFI library, where you don’t want the C pre-processor to have to stay installed when using the binding library), or when the compilation is messy, e.g. it uses files from the build directory that aren’t installed in the .scm and .go directories (and don’t make sense to be installed there).
And in the situation where all used modules are precompiled and already in the load paths (e.g. modules of Guile itself, or installed with package manager), then no caching happens at all.
➢ - if you have two module, a.scm and b.scm, a imported b's function to use. 
- the .scm are in ./mod directory.
- compile them and put into ./obj/mod directory.
- guile -C obj -L .
- (load-compiled "obj/mod/a.scm.go")
- 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.
You missed ‘-C’ (load-compiled-path). You can point this to a cache if you wish, but it doesn’t need to be a cache. 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 exis.
➢ So the problem is, if you want to bypass the caching, you have to provide your manual caching comprehensively.
No. You can disable caching without providing manual caching. E.g., in case of %.go:%.scm Makefile rules (+ dependency information which in principle could be automatically generated by guild, but currently isn’t yet), make takes care of compilation. Because of its local nature (no shared cache) (^), lack of capacity limits (no time limits, no size limits) and its aesthetics (it’s just compilation) (*), this is not a cache system.
(*): for a comparison: you can compile C code to a shared and install it in /usr/lib without /usr/lib being a cache – being a cache is more about how it is populated and maintained than it is about what it happens to contain.
(^): not a strict requirement for a cache, but it’s an indication when the ‘known cache’ (that thing in .cache/) is a different and more global thing.
Another option is to only precompile the a.scm (and not additional dependencies) and disable autocompilation (when there’s only a single file to take care of, comprehensive is trivial).
A third option is to use potentially outdated  .go (unfortunately Guile doesn’t fully separate caches from precompiled code, so beforehand you need to update the timestamps to make Guile accept them). This can then be separation of ‘code I'm currently writing, which might be in a not-ready state, but I already saved it to not loose it in case the computer needs to suddenly shut down’ and ‘latest ‘good’ version of the code – might be incomplete, but is ready for testing’. (Other methods exist too, but this can be convenient.)
➢ The relative easier way would be modify the loading path on the fly with Guile related API.
You can indeed modify the loading paths from within Guile (I previously mentioned this myself). But this doesn’t help with loading the first .go  (so it’s not an easier way, it’s not a way) – if a.scm sets up the load paths (including compiled path), then by the time that Guile can know where a.go is located, it’s too late for that. So, either you need to:
(0) not precompile a.scm (it’s pointless)  (and for dependencies adjust load paths when needed, in invocation or in a.scm)
(1) install a.go somewhere in the standard load-compiled-path (not always possible) and just ask guile to load a.scm (-> guile loads a.go instead)
(2) add ‘-C insert-go-directory-here’ to the guile invocation (straightforward, but not the best option) and load a.scm (-> guile loads a.go instead)
(3) tell Guile to load a.go, and let a.go set load-compiled-path (& load-path) to find remaining dependencies
Of these four options, (0) and (3) have the most convenient invocation. Of those two options, (3) has the least re-compilation. By these criteria, (3) is the best.
Best regards,
Maxime Devos