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’.