[bug#65860] [PATCH 0/4] Resolve a circular module dependencies in embedded modules

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> People will lose the ability to install those toolchains, for instance
>> with ‘guix install propeller-toolchain’, or to upgrade profiles that
>> contain them (though ‘guix install axoloti-runtime’ is still good, for
>> instance).
>>
>> I’m not sure whether that’s acceptable, but we should check with known
>> users of this, such as Ricardo.
>
> It's a pity to loose that ability (it's also a pity to not be able to
> simply 'guix install gcc-cross-some-target', for the same reason) but
> the statu quo where pulling (gnu packages avr) causes hard to grasp
> failures is worst, in my opinion.  I wasn't able to work on adding
> packages dependent on (gnu packages avr) for that reason.  Debugging was
> a pain.

Oh yes, I’ve been there, so I can tell you I sympathize.  :-)

I agree that this needs to be addressed.  I wondered whether/how hard we
should search for a different solution.

>> I’ve always felt that these toolchains should be provided as part of the
>> “regular” cross-compilation framework in cross-base.scm.  Packages that
>> always need to be cross-compiled (to AVR microcontrollers, etc.) would
>> have a hardcoded #:target in their ‘arguments’ field.  I forgot why this
>> was rejected.
>
> That'd be an improvement, I think.  Right now we have to call a
> procedure in the input fields everywhere, it's not very elegant.

BTW, another issue with the package-returning procedures: they return a
fresh package object at each call, which defeats caching.  I think you
should be able to observe it with:

  GUIX_PROFILING=object-cache guix build axoloti-runtime -d  --no-grafts

The effect will be more acute on the build farms since they compute
derivations for everything that depends on these toolchains.

The solution would be to make those procedures memoizing, with ‘mlambda’
or similar.

Ludo’.