On Wed, 27 Mar 2024 12:22:40 +0100 "pelzflorian (Florian Pelz)" wrote: > Hi there. [...] Hi > Denis 'GNUtoo' Carikli writes: > > On Mon, 25 Mar 2024 18:34:18 +0100 > > "pelzflorian (Florian Pelz)" wrote: > >> Hello, what you intend does sound very interesting. As for “guix > >> time-machine”, I do not see the problem [...] > > Let's say a user install Guix 1.4.0 and GNU Boot use a guix commit > > after v1.4.0, as I understand guix time-machine will fail. > > No, it does not fail. Thanks a lot, this is very interesting as it could simplify a lot the code. In addition running guix time-machine doesn't modify the current Guix version so it's not invasive. I recall that when I tried it on older versions of Guix, it did fail, but maybe more recent versions don't fail anymore. I'd need to do more tests with that to understand when it fails or doesn't fail and somehow get/require the right conditions and then remove all the code that isn't needed anymore. > >> I do not know, but maybe the Autotools of Guix itself use something > >> like this to deal with “make -j4”. > > My question was more about the user interface and if it was the > > right thing to do. As for the code implementing it[1], it was > > pretty easy to do for me and it integrates fine with the current > > GNU Boot structure: if users run './autogen.sh && ./configure' they > > can still use the scripts manually, so this avoids too much > > invasive changes. > > So from reading the Guix build machinery, Makefile.am runs > > https://git.savannah.gnu.org/cgit/guix.git/plain/build-aux/compile-all.scm > > and they use (getenv "MAKEFLAGS") to check if make gets any > --jobserver flag that specifies the number of parallel compilations. > This seems slightly nicer than a non-standard configure option, but > is also more complicated in that Makefile.am calls out to > compile-all.scm to do the work. Thanks for that information. This could make things work out of the box without more configuration. Though I still need to think about that one as the code is much harder to understand than with configuration options. > Why do you need so many different Guix versions? Are there > regressions or is it just that you have tried building different > parts of Libreboot with different versions of Guix? We don't necessarily need multiple Guix versions but I think it fits better in the current design if we allow that. The old structure of Libreboot we inherited was converted to look more like packages. Now each "package" has a directory in resources/packages/ like resources/packages/grub for instance. And inside the package directory there are shell scripts with specific names like download, build that are tasks. Because of that it makes sense to treat each "package" separately and allow the use of different Guix versions. So practically speaking if I want to replace the code that builds SeaBIOS with shell scripts I could first write a local guix seabios-coreboot package that I add inside resources/packages/seabios/seabios.scm and call guix build inside resources/packages/seabios/payload (which builds SeaBIOS for Coreboot). At this point I could use Guix 1.4.0 if there are no security issues in SeaBIOS or its dependencies for Guix 1.4.0. But once seabios-coreboot is upstreamed in Guix it would make sense to get rid of resources/packages/seabios/seabios.scm completely if possible (if we use the same build options, don't have extra patches, etc) and instead update the shell script that calls guix build to use the Guix version where seabios-coreboot was added. Thanks to that it's easier to update each package without affecting the rest. When everything will have been converted to use Guix packages we would need to think again if using a single Guix revision could make sense or not depending on the amount of risk of breakages. The main advantage of a single revision would be to have way faster builds. > That is, you move Libreboot’s build system stepwise towards using guix > build instead. Sounds good from outside; I have not perused all the > links throughly. It is very interesting, though. The main rationale behind that is to have at any point something that still works. Using Guix just for specific packages like GRUB enable to test the resulting images like with any other changes, and also consistently update the documentation along the way and so on. We can even write some automatic tests that work with images made before Guix is integrated and after without needing any special consideration. And finally it also lowers a lot the odds of having never-ending work to do the conversion, and never finishing nor making any releases, especially because some of the tasks (like building Coreboot) are not trivial (it requires an ada compiler and Guix doesn't have one yet). And all that also makes it easier to collaborate with upstream as we don't need to rush to convert everything to Guix packages, so it leaves time to upstream things. Denis.