Hi, Mathieu Othacehe <m.othac...@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’.
