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" <l...@gnu.org> a écrit : >Hello! > >Ludovic Courtès <l...@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’.
