From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 18247@debbugs.gnu.org
Subject: bug#18247: Cyclic dependencies in (gnu package *) modules
Date: Mon, 11 Aug 2014 19:59:37 -0400 [thread overview]
Message-ID: <87y4uupogm.fsf@yeeloong.lan> (raw)
In-Reply-To: <87d2c6razd.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 11 Aug 2014 23:07:50 +0200")
ludo@gnu.org (Ludovic Courtès) writes:
> mhw@netris.org skribis:
>
>> I'm currently unable to compile guix from git, with error messages that
>> suggest cyclic dependencies between the modules.
>
> Indeed. That is fixed by reverting c5d8376. Can you confirm?
Yes, that solves the problem for me.
>> I just computed the strongly connected components of the (gnu package
>> *) modules. The non-trivial ones are listed below.
>>
>> There are three cycles of size 2:
>>
>> ((gnu packages emacs) (gnu packages version-control))
>> ((gnu packages flex) (gnu packages bison))
>> ((gnu packages python) (gnu packages zip))
>>
>> And one large strongly-connected component containing 51 modules:
>
> Ouch.
>
> Well, that is not really a problem per se. The real problem is when
> top-level bindings refer to each other, of course.
To be more precise, the relevant question is: which bindings from other
modules are needed when a module is _loaded_. In other words, we need
to worry about cycles in a graph, but a different graph than the one my
script computed.
I think the graph we need to consider is one that contains one vertex
per module, and an directed edge from module A to B if and only if
loading module A requires looking up a binding from module B.
Does that sound right to you?
Unfortunately, it seems to me that the most common kinds of cross-module
references between (gnu packages *) modules are references in 'inputs'
or 'native-inputs' fields, and those need to be looked up at module load
time, right?
> But anyway, I agree we need tooling or something to help deal with this
> kind of issues. Perhaps something like the script you posted, but that
> would look at the set of bindings referenced from the top-level of a
> module? Or can we do better?
>
> If Guile supported phases, such circular references would not be a
> problem since it would not have to evaluate all of the imported modules
> at expansion phase, just the ‘define-module’ clause.
I'd very much like to add phases to Guile's macro expander at some
point, but it would have to be done between major releases. It would
likely break a lot of existing code.
Thanks,
Mark
next prev parent reply other threads:[~2014-08-12 0:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 20:05 bug#18247: Cyclic dependencies in (gnu package *) modules mhw
2014-08-11 20:49 ` mhw
2014-08-11 21:07 ` Ludovic Courtès
2014-08-11 23:59 ` Mark H Weaver [this message]
2014-08-12 3:28 ` mhw
2014-08-12 7:31 ` mhw
2014-08-12 13:54 ` Ludovic Courtès
2014-08-12 20:53 ` Eric Bavier
2014-08-13 18:55 ` Mark H Weaver
2014-08-13 22:09 ` Ludovic Courtès
2014-08-16 6:00 ` Eric Bavier
2014-08-16 9:11 ` Ludovic Courtès
2014-08-28 9:41 ` Ludovic Courtès
2014-08-12 11:05 ` Ludovic Courtès
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=87y4uupogm.fsf@yeeloong.lan \
--to=mhw@netris.org \
--cc=18247@debbugs.gnu.org \
--cc=ludo@gnu.org \
/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).