Hey, it's Friday night! So what am I doing?
Oh, right, I'm waiting for rust to build. It'll be a while...
It'll probably finish some time on Sunday, this machine is ancient and slow and small and I would really do well to replace it with something more modern. I guess I could shop for a new build server (more affordable than the one I have at work, anyway).
(This poor old server is a 6-core Dell R415 from 2012 with only 16GB of RAM. It has served me pretty well but modern software is just too resource-intensive.)
I remember when I had to do all this stuff sequentially, on three different machines, and I'm glad that era is well and truly over now.
Update: gcc took nine hours to build. node only took five.
rust finally finished building after nearly fourteen hours, so now it's on to building llvm (two different versions), which have both been going for about four hours now. (Both depend on py311-recommonmark, which depends on rust.)
llvm requires a lot less temporary space than rust to build but I'm not sure how the heap footprints compare. I'm limited to four parallel builds on this machine because it doesn't have the memory -- sometimes it doesn't even have the memory for that, depending on whether the topological sort ends up scheduling multiple space hogs in parallel. Right now building qt6-declarative and webkit2-gtk3 in addition to the two compilers.
In case anyone's wondering (probably not) llvm15 and llvm17 are still building, now both at 16 hours 28 minutes in. Everything else that can be built has been, leaving just 24 downward dependencies of one or both of the two compilers.
llvm15 finally finished (llvm17 is still going). Just building the tarball for the package took 14 minutes 20 seconds (it's a *huge* package). apparently, `spirv-llvm-translator`, `qt6-tools`, and the expected `postgresql14-server` are the immediate dependencies that can now start building. I haven't the foggiest idea what `spirv-llvm-translator` is; apparently X depends on it for some reason.
Package build finished overnight. To my total surprise, firefox took less than six hours to build. The whole set (732 packages needing rebuild out of 1,345 total) took just under 46 hours.
@feld @karinjiri My build system at work was donated by a startup that was liquidating and had to clear out their DC pronto, 72-thread Xeon in a Supermicro chassis. I put 512 GiB of RAM in it; the drives are boring Samsung SATA. It's still plenty fast enough that our (much smaller, non-desktop) package build is pretty much serialized. (Critical path is curl -> cmake -> rust -> llvm -> postgresql-server... most of the builders are idle before rust finishes.) Ofc everything in our DCs is headless.
@karinjiri Because I am bad at automation, almost all of my servers are built by cloning; I don't think I've run the actual official FreeBSD installer in more than 15 years. (This means, among other things, that we have a "nonstandard" ZFS root layout that doesn't play nice with boot environments.) Back in the mists of ancient time I made the i386->amd64 transition via `make installworld`, twice.
The coworker who did our Linux installer wants to do a FreeBSD one but I don't expect it to work.
@wollman why build and not download?
@rsalz Because I need certain build options set in a way that the public package repository does not, and it's important to me to have a self-consistent package set (especially when I have to do things like upgrading postgresql, which is going to be in my future soon enough).
@wollman thanks for explaining
@rsalz Normally this would be a "set it and forget it" process but I forgot to start the build under screen so now I'm stuck with having that xterm open until it finally finishes. I also *just did* a build and wasn't planning on having to do this one, but I do want the updated Firefox ASAP. One of the unfortunate down sides of the switch to git is that you now have to update the whole repo at once; with svn I could just update the recipe for ffx and build only that, holding upward deps fixed.
@wollman I cannot imagine an environment that needs particular build flags that must be propagated from the compilers and languages on up. But that's okay, I don't have to. You've got it, and you know what you're doing. Good luck with that!
@rsalz Oh, they don't. But the build system is designed to ensure that all of the packages are consistent and build reliably from the recipe and configured options, which means rebuilding rust and llvm and everything that depends on them whenever curl changes. Poudriere doesn't know that curl is unlikely to affect postgresql-server through whatever long chain of dependencies, it always takes the most cautious approach to ensure there can never be an inconsistency.
@wollman It translates the SPIR-V intermediate representation for shaders to LLVM I think, unless it's the other way around. Maybe Mesa uses it somehow?