And it’s nice to point out the downside of broken incremental builds, which is very common, and lack of parallelism, which Bazel does solve well.
It has been my dream since the publication of Bazel as open source to have a Bazel-based build of NetBSD. I think Bazel is the perfect build system for such a project because it’d deliver correct and efficient incremental builds to NetBSD’s monorepo, and it would save tons of resources when running on many-core machines.
Except for the fact that it’s written in Java,
But I wonder if it’s simpler to just take the action / process wrappers from Bazel. There is separate code for Linux, Darwin, and Windows, because sandboxing processes is extremely platform-specific
The main thing it lacks is exactly the process sandboxing to find missing dependencies, and thus guaranteed correct incremental builds – basically because I haven’t bothered to write a process sandbox thingy.
It hasn’t come up too much in practice for us, but it would for a huge build.
This system has been working well – we just added say Soufflle datalog, which generates C++, which analyzes our statically typed Python code. And then that builds C++ in many configurations. That is, it can do complex Bazel-like things pretty naturally, just without sandboxing now.
We don’t have cross-compiling either, though I think that is basically just passing a flag, once you have the right compiler
I’d take a look at Samurai, if you’re in a market for a ninja-like tool: https://git.sr.ht/~mcf/samurai. It’s 4000 lines of code, and performs just as well as Ninja.
I am not sure if they do the action sandboxing thing, but building an embedded Android image is extremely similar to building embedded NetBSD, so those could be good options
Although I just use Python as the meta build language! That works nicely
Someday I will experiment with the process wrapper
This year, I ran into a scenario where I wanted to run MySQL v5 and v8 side by side on my local dev machine - an M1 Macbook.
While I had MySQL v8 running through the official macOS distribution, by that point in time, official distribution for MySQL v5 for macOS had stopped existing. I didn’t have much faith in Homebrew (which also had deprecated v5 anyway).
NetBSD’s package manager pkgsrc surprised me. I was able to get MySQL v5 built and running through pkgsrc on macOS aarch64 without a hitch. Impressive considering that it was also my first encounter with NetBSD ecosystem.
pkgsrc is a framework for managing third-party software on UNIX-like systems, currently containing over 26,000 packages. It is the default package manager of NetBSD and SmartOS
i.e. do they share some logic?
I remember seeing some tweets about building all packages on SmartOS and being pretty impressed. I think the equivalent of building all Debian packages is not nearly as nicely automated (though of course Debian has many more packages)
Nope. pkgsrc shares no logic with NetBSD’s build system. (There are some packages inside pkgsrc that do use NetBSD’s own bsd.*.mk files, but the core infrastructure of pkgsrc does not.)
It’s not quite as portable but Chimera Linux’s cbuild tool can build or cross-compile packages on any Linux system with apk-tools. I use this to build packages on my Arch desktop destined for my servers running Chimera.
Great overview!
And it’s nice to point out the downside of broken incremental builds, which is very common, and lack of parallelism, which Bazel does solve well.
But I wonder if it’s simpler to just take the action / process wrappers from Bazel. There is separate code for Linux, Darwin, and Windows, because sandboxing processes is extremely platform-specific
https://github.com/bazelbuild/bazel/tree/master/src/main/tools
https://bazel.build/docs/sandboxing
Then you can use Ninja to invoke the sandboxed actions, and avoid Java altogether.
Also I think Buck2 is written in Rust, which creates some bootstrapping problems. Plus NetBSD has limited, tier 3 Rust support - https://doc.rust-lang.org/nightly/rustc/platform-support.html
By comparison, Ninja is a small C++ program (like less than 20K lines, with no deps at all, IIRC)
I wrote a mini-Bazel that uses Ninja, and Oils developers have been using it for over 2 years now
https://www.oilshell.org/blog/2022/10/garbage-collector.html#declarative-ninja-mini-bazel
The main thing it lacks is exactly the process sandboxing to find missing dependencies, and thus guaranteed correct incremental builds – basically because I haven’t bothered to write a process sandbox thingy.
It hasn’t come up too much in practice for us, but it would for a huge build.
This system has been working well – we just added say Soufflle datalog, which generates C++, which analyzes our statically typed Python code. And then that builds C++ in many configurations. That is, it can do complex Bazel-like things pretty naturally, just without sandboxing now.
We don’t have cross-compiling either, though I think that is basically just passing a flag, once you have the right compiler
I’d take a look at Samurai, if you’re in a market for a ninja-like tool: https://git.sr.ht/~mcf/samurai. It’s 4000 lines of code, and performs just as well as Ninja.
Hm I realized I wrote a related comment about GN in Chrome, Blueprint in Ninja, with links:
https://lobste.rs/s/0qc6vp/arcan_0_6_3_i_pty_fool#c_ahqwky
I am not sure if they do the action sandboxing thing, but building an embedded Android image is extremely similar to building embedded NetBSD, so those could be good options
Although I just use Python as the meta build language! That works nicely
Someday I will experiment with the process wrapper
This year, I ran into a scenario where I wanted to run MySQL v5 and v8 side by side on my local dev machine - an M1 Macbook.
While I had MySQL v8 running through the official macOS distribution, by that point in time, official distribution for MySQL v5 for macOS had stopped existing. I didn’t have much faith in Homebrew (which also had deprecated v5 anyway).
NetBSD’s package manager pkgsrc surprised me. I was able to get MySQL v5 built and running through pkgsrc on macOS aarch64 without a hitch. Impressive considering that it was also my first encounter with NetBSD ecosystem.
Hm wow, that is impressive … Yeah I was going to ask how the
build.shin this post relates topkgsrc(https://github.com/NetBSD/src/blob/trunk/build.sh - 3000 lines of shell)
https://pkgsrc.org/
i.e. do they share some logic?
I remember seeing some tweets about building all packages on SmartOS and being pretty impressed. I think the equivalent of building all Debian packages is not nearly as nicely automated (though of course Debian has many more packages)
Nope. pkgsrc shares no logic with NetBSD’s build system. (There are some packages inside pkgsrc that do use NetBSD’s own bsd.*.mk files, but the core infrastructure of pkgsrc does not.)
Sorry my comment is only tangentially related. I was heaping praises about my only interface with the NetBSD ecosystem - pkgsrc package build system.
I’d like someone to write a similar post about pkgsrc!
I think it is somewhat similar to what Aboriginal Linux was supposed to be for Linux: http://landley.net/aboriginal/
Looks like you can build NetBSD on an OS X system, and you can cross compile. Probably you can build SmartOS on a NetBSD system, etc.
They probably solved a whole bunch of bootstrapping problems (and limited themselves to POSIX and such, which is hard)
It’s not quite as portable but Chimera Linux’s cbuild tool can build or cross-compile packages on any Linux system with apk-tools. I use this to build packages on my Arch desktop destined for my servers running Chimera.