[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) |
Hi,
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.
Thoughts?
(The <canonical-package> trick you posted should work of course, but
it’s even better if we can avoid it!)
Thanks,
Ludo’.