bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Maxim,

Maxime Devos <maximedevos@telenet.be> writes:

> On 19-08-2022 22:37, Maxim Cournoyer wrote:
>
>> Hi Maxime.
>>
>> Maxime Devos <maximedevos@telenet.be> writes:
>>
>>> Can't reproduce after touching java-utils.scm.
>> I got this issue a couple times too.  I attributed it (without analysis)
>> to Guile's failure to keep track of changes to macro expanded code.
>
> It might be inlining. I don't see how macro expansion matters here. I
> think it's dependency tracking in general.

Dependency tracking is probably what I meant.

>> More like something to track on the side of Guile, I would think.
>
> I had a patch for build-aux/compile-all.scm that adds a form of
> dependency tracking: <https://issues.guix.gnu.org/50384>. If we teach
> it about (define-module (foo) #:use-module (bar)) --> (bar) is a
> dependency of (foo) (using parts of source-module-closure?) (and drop
> the search-patch things), then it seems solved to me.
>
> As there is a known path to a solution, I wouldn't close this.
>
> These patches are for Guix' build system.  I don't see anything that
> could be done on the Guile side, except for eventually migrating some
> dependency tracking stuff over to Guile

If a module imports a different module, and that module changes, even if
it's macro, Guile should not blindly reuse the stale .go like it
currently does.  It should complain and evaluate from source instead.

That would cover the base and avoid breakage.  After, if it known how to
do that, yes, it seems it'd be useful to have something similar to 'gcc
-M' to provide the needed intelligence to the build system.

Does that make sense?

Thanks,

Maxim