bug#32160: auto compile fails to recompile when included source files change

[Mark H Weaver]

Hi Arun,

Arun Isaac <address@hidden> writes:

> Guile's auto compile fails to recompile when included source files
> change.
>
> For example, I have two source files -- foo.scm and bar.scm. foo.scm
> includes bar.scm using `include'. When I run foo.scm for the first time,
> it is auto compiled and run correctly. But, if I modify bar.scm and run
> foo.scm again, foo.scm is not rebuilt and the old version is run.

Yes, this is a known limitation in Guile's auto-compilation support.
Unfortunately, we don't have any system in place to track these
dependencies between modules.  Years ago, I spent some time thinking
about how to do it, but it's nontrivial given the unstructured and
imperative model by which modules load themselves and their
dependencies.  The .go file format would also need to be extended to
embed the dependency information.

There's also the question of how to fingerprint the dependencies.  If
timestamps are used, it would defeat deterministic builds, but if hashes
are used, it might dramatically slow down module loading, especially
given that it would not be sufficient to check the immediate
dependencies: the full transitive closure of the module dependency graph
would need to be traversed.

And then there's the unfortunate fact that although circular module
dependencies are (sensibly) prohibited by standard Scheme and most other
languages, in Guile they are not prohibited, and although they cause a
great many headaches, they sort-of-work if you are lucky, and Guix now
depends heavily on them.  Last I checked, Guix has a large number of
package modules (well over 50, and possibly more than 100 at this point)
that form a strongly connected component in the module dependency graph.

I'm sorry that I don't have a better answer for you.  If you'd like to
investigate further, I'd be glad to give you pointers and advice, but
it's not a project for the faint-hearted :-/

      Regards,
        Mark