l...@gnu.org (Ludovic Courtès) writes:
> m...@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
