bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57121: clojure-build-system fails to compile -- backtrace from langu


From: Maxime Devos
Subject: bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm
Date: Tue, 23 Aug 2022 11:07:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0


On 23-08-2022 06:06, Maxim Cournoyer wrote:
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

On 22-08-2022 17:32, Maxim Cournoyer wrote:
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?
Sounds reasonable, though we could go for something less general in
Guix first.
I'd rather avoiding adding more complexity in Guix if it can be fixed
upstream; where it'd benefit everyone most.

It cannot be solved upstream, this is not a pure Guile matter but also a build system matter. Even if this the 'if that module changes, it ... should evaluate from source' was implemented, the build system still needs to know to compile the module.

More concretely, build-aux/compile-all.scm uses the following to determine what needs to be recompiled:

(define (file-needs-compilation? file)
  (let ((go (scm->go file)))
    (or (not (file-exists? go))
        (file-mtime<? go file))))
--- just interpreting imported modules that have changed doesn't cause the importing module to be recompiled.

Also, at least one Guile maintainer wants dependency tracking to be orthogonal:

<https://issues.guix.gnu.org/50960#59>
I guess I could live with an 80% dependency tracking solution. However,
my criteria for it would be that (1) it should be orthogonal (e.g., not
requiring explicit calls to ‘notice-dependency’ in many places), and (2)
it should be self-contained and reasonably small. Perhaps having
‘load*’ or similar instrument ‘open-file’ or similar could help achieve
that?

Your proposal to do in Guile does not appear to match that criterium.

The notice-dependency could be eventually upstreamed, but the issue does not appear to be fixable upstream.

Greetings,
Maxime.

Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]