> 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".
On Sun, Dec 15, 2024, 01:10 Maxime Devos <maximede...@telenet.be> wrote: > > - 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 > > >
