Hello! Ludovic Courtès <l...@gnu.org> skribis:
> This patch set leads us to a ‘guix pull’ that creates several > derivations instead of just one: “guix-core” (38 files), “guix-extra”, > “guix-packages” (388 files), “guix-cli”, “guix-system”. > > The idea is that we should be able to have substitutes for at least some > of them, for instance because “guix-core” doesn’t need to be rebuilt > very often. Most of the time, users will just have to build > “guix-packages”, which is still a bit slow, but will hopefully get > better as Guile incorporates those long-awaited fixes. I’ve just pushed this, let me know how ‘guix pull’ works for you! In addition to this, I’ve created a Hydra job to build this new “modular Guix”: https://hydra.gnu.org/jobset/guix/modular If everything goes well, this should give us substitutes for at least “guix-core” and “guix-extra”. We have yet to see how long it takes to evaluate it on hydra.gnu.org and adjust the evaluation frequency accordingly. > The ‘reload-guix’ procedure there is here to fix that: we reload all the > Guix modules of the target checkout, and run the build procedure from > that context. Unfortunately, it’s not fully baked yet because reloading > leads to incompatibilities: the (guix scripts pull) module remains in > the “old world” and manipulates the old <derivation> and <package> > record types, which is different from the new ones. That should be > fixable, but requires some more time and fiddling. Help from Guilers is > very much welcome! :-) This part is currently commented out, it needs more work. The main issue is performance: we end up evaluating or building a lot of modules, notably package modules, and again we hit the performance issues of the compiler in Guile 2.2.2. Ludo’.
