At Mon, 8 Jun 2020 15:09:47 +0100, David Brownlee <abs%absd.org@localhost> wrote: Subject: Re: Optional crunchgen base (Was: Postfix and local mail delivery - still relevant in 2020?) > > On Sun, 7 Jun 2020 at 18:35, Greg A. Woods <woods%planix.com@localhost> wrote: > > [...] > > To really make this useful for general NetBSD builds will take some more > > hacking on the build system (basically it might go something like always > > building a ".cro" file for every program possible, then generating a > > crunchgen config to link them all together and generate an mtree file to > > generate all the (sym)links; and possibly doing it on a per-set basis > > (e.g. one binary for base, one for the toolchain, one for x11, or > > something like that). > > Would it be possible to persuade you to take a look at this for > current NetBSD? If it was possible to build base like this it would > give an opportunity for people to test on a variety of older and > memory constrained boxes... I am slowly working at it! A little less slowly now that I don't have a $dayjob to interfere. The way I did the experiment for netbsd.NET5501.EMBED was far too hackish as it was based on the installer image build, and that requires re-compiling every program for every image. It didn't take a lot of work to do initially though as the ramdisk image builds already held all the necessary infrastructure and machinery to do it. I've only recently come up with the idea of doing the *.cro builds in parallel with regular builds. I fact it would probably be nearly as efficient to also build both dynamic-linked and static binaries all at the same time too. However I've since been struggling with how to create sets and/or final bootable images in a more efficient and flexible manner. I recently realised that it might be possible to have the sets-building scripts generate the sets dynamically with symlinks and to also do the final link step of the ramdiskbin itself (based on what programs were being pulled into the set file). As-is this might require some info be made available showing where the objdir for each program is (and this might be automatically generated when the normal binary is installed, e.g. as part of the mtree file). Sets could then also be used to create the ramdiskbin for all ramdisk images that currently use separately compiled crunchgen files. That way even if you wanted to build a bootable image with some different combinations of programs, e.g. base+misc+text, all the required programs could still be linked into the same ramdiskbin. Alternatively a "master" destdir could be built where every program is actually in a sub-directory (e.g. as in macOS .app dirs), and then the sets builders and image builders could choose either the static binary, the dynamic-linked binary, or the .cro file when creating the final filesystem image. And of course only one kind of binary would have to be built, with the others only built as options. All-told though any of this may be a pretty invasive change to the build overall, but would probably worthwhile in order to achieve the necessary efficiencies. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpFzUN5VTkgF.pgp
Description: OpenPGP Digital Signature