Re: Cross-compilation broken on canonical packages.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> This is expected: packages in ‘%final-inputs’ (those returned by
>> ‘canonical-package’) are rooted in the bootstrap graph and cannot be
>> cross-compiled.
>
> Looking at canonical-package in (gnu packages commencement), I see that
> there's already a switch on (%current-target-system). The given package
> is directly returned if (%current-target-system) is set, which appears
> to be what we want!
>
>          ;; In general we want CANON, except if we're cross-compiling: CANON
>          ;; uses explicit inputs, so it is "anchored" in the bootstrapped
>          ;; process, with dependencies on things that cannot be
>          ;; cross-compiled.
>          (if (%current-target-system)
>              package
>              canon))
>
>
> But, this doesn't work as expected. I guess it is because of
> (%current-target-system) evaluation time.

Ah yeah.  The hack works when you use ‘canonical-package’ in a package
input, because package input fields are “thunked”, so they’re evaluated
in a dynamic context where ‘%current-target-system’ has the right value.
  
However, the hack doesn’t work for things like the ‘packages’ field of
<operating-system> because it’s not a thunked field.

Two simple solutions here, I think:

  1. Make ‘packages’ a thunked field.

  2. Stop using ‘canonical-package’ altogether in ‘%base-packages’.

I actually have a preference for #2.  We’d need to check what impact it
has on the system closure size, but I suspect it’s going to be minimal.

Thoughts?

(The <canonical-package> trick you posted should work of course, but
it’s even better if we can avoid it!)

Thanks,
Ludo’.