[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-compilation broken on canonical packages.

From: Ludovic Courtès
Subject: Re: Cross-compilation broken on canonical packages.
Date: Mon, 30 Dec 2019 19:48:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Mathieu Othacehe <address@hidden> 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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]