If we aim at merging c-u before next release, we should probably wait next cycle, as this introduces quite a lot of changes, and packages might break in subtle ways.

10% increase for computing derivations is not great :/ it already takes a long time to do that on my arm system ^^". I wonder how we could improve that?

Le 10 mars 2021 06:09:23 GMT-05:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello!
>
>Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Over the last few days I’ve been head-down working on
>> ‘wip-build-systems-gexp’, the mythical branch that brings gexps to
>build
>> systems and packages, so we can say goodbye to
>> ‘build-expression->derivation’.  And… it’s quite a ride!
>
>The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being
>built,
>it can build ‘guix’ and cross-build things like ‘sed’:
>
>https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
>
>  https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
>  currently has unrelated problems)
>
>In terms of performance, there’s still a ~10% slowdown when computing
>derivations compared to the ‘core-updates’ revision the branch is based
>on.
>
>Here’s what I’d like to do in the coming days, if that doesn’t
>interfere
>with what others have in mind for the upcoming release:
>
>  • Monitor build failures due to typos/thinkos made while adjusting
>    build systems;
>
>  • Merge on ‘core-updates’.
>
>Then there are optimizations to work on, but that can take a bit
>longer.
>In particular, in ‘gexp->derivation’, allow file-like objects to be
>specified as environment variable values.  In turn, use that so that,
>say, ‘gnu-build-system’ has a single builder for all its packages and
>just calls ‘getenv’ to get the value of its various parameters, similar
>to what (guix git-download) does.
>
>That said, if people think it’s too late in the cycle, we could just as
>well keep it for the next cycle.
>
>Thoughts?
>
>Thanks,
>Ludo’.