unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 57121@debbugs.gnu.org
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	[thread overview]
Message-ID: <ae2686e0-0ad3-1ae6-cfae-9340e5b6868b@telenet.be> (raw)
In-Reply-To: <87y1vffvsv.fsf@gmail.com>


[-- Attachment #1.1.1.1: Type: text/plain, Size: 2417 bytes --]


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 #1.1.1.2: Type: text/html, Size: 3823 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2022-08-23  9:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10 16:59 bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm Maxime Devos
2022-08-10 17:42 ` Maxime Devos
2022-08-19 20:37   ` Maxim Cournoyer
2022-08-19 20:58     ` Maxime Devos
2022-08-22 15:32       ` Maxim Cournoyer
2022-08-22 18:10         ` Maxime Devos
2022-08-23  4:06           ` Maxim Cournoyer
2022-08-23  9:07             ` Maxime Devos [this message]
2022-08-27 15:53               ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae2686e0-0ad3-1ae6-cfae-9340e5b6868b@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=57121@debbugs.gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).