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

[Maxim Cournoyer]

Hi,

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Partially addresses <https://issues.guix.gnu.org/65716>.
>>
>> * gnu/packages/avr.scm: Add commentary comment.
>> (avr-gcc): Turn into this...
>> (make-avr-gcc): ... procedure.
>> (avr-libc): Likewise, into...
>> (make-avr-gcc): ... this.  Adjust native-inputs accordingly.
>> (avr-toolchain): Likewise, into...
>> (make-avr-toolchain): ... this.
>> * gnu/packages/avr-xyz.scm (simavr) [propagated-inputs]: replace 
>> avr-toolchain
>> with a call to the 'make-avr-toolchain' procedure.
>
> [...]
>
>> Fixes <https://issues.guix.gnu.org/65716>.
>>
>> Before this change, simply adding the following import:
>>
>>   modified   gnu/packages/firmware.scm
>>   @@ -42,6 +42,7 @@ (define-module (gnu packages firmware)
>>      #:use-module (gnu packages admin)
>>      #:use-module (gnu packages autotools)
>>      #:use-module (gnu packages assembly)
>>   +  #:use-module (gnu packages avr)
>>      #:use-module (gnu packages backup)
>>      #:use-module (gnu packages base)
>>      #:use-module (gnu packages bash)
>>
>> Would cause byte compilation and/or evaluation to fail due to a circular
>> module dependency.

[...]

> 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.

> 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.  Until
then, the change proposed here seems the best we can do.  I've been
adding new avr-dependent firmware packages in (gnu packages firmware)
happily on top of it.

-- 
Thanks,
Maxim