Why read on? To learn how Minix could effortlessly crossbuild from all these environments.
Software that always works is pretty hard to achieve. It depends
on its own state and the state of its environment. Its own state
is hard enough to manage as it is. That of the environment, however,
is outside of its control alltogether. Whenever I use something that is
highly dependent on its environment, and it works without fiddling,
I'm always surprised and impressed and pleased. It's such a nice
experience. Example: my SONOS players.
Phones nowadays (I use Androids) do a really good job of it too.
Apple also seems to invest a lot into the 'just works' experience
and it's impressive how often it does, in fact, just work.
I've come to appreciate both the value of things that just work,
and the cost of getting things to just work, a lot, because I'm on
both sides of the fence. I co-provide a product that should work;
and I'm a consumer of many products that should work. It's easy
to underestimate how much more complex something has to be if it
has to work for everyone, in any environment, compared to just for you.
You got it working in your environment, after all.
I'd like it if Minix never had any build problems. (Let's not talk
about run problems for now - that's much harder to measure.) But
we're a pretty small team so can't go down the long
tail of reasons why builds
might break in many different environments.
Minix can be cross-built for x86 or ARM and so relies on its host
environment to a degree. This can't be controlled, so to have a
robust build system that not only works but also doesn't break
easily is pretty hard.
Fortunately we consciously decided to re-invent the wheel as little
as possible and so went with NetBSD's
build system. Their approach shows they recognize the same problem
and they solved it very neatly. All dependencies - from small
utilities like stat to a crossbuilding compiler and linker - can
be packaged along with the NetBSD source and built as `tools' before
NetBSD itself is. The build process then uses the tools and no host
commands. So the dependencies on the host environment are minimized.
This is crucial; just a simple utility like stat not taking exactly
the expected option and produce exactly the expected output could easily
break the whole build - often a hard-to-diagnose problem given the
I should add that, powerful as the system is, it is not magical.
When used properly, the system provides reproducibility of builds
independent of the host environment. This doesn't mean there are
no problems. It means the state is manageable and only minimally
dependent on the host environment. In the best case, all problems
are solved just once. Once it is solved by the first person, someone
else shouldn't bump into it again. Even if the hosting environments
are different. Given how diverse such environments can be, that
does make it quite magical as far as I'm concerned.
The buildsystem has worked really well for Minix as well. Just to
see how well it does on many different Linux distros, I tried
crosscompiling x86 Minix on the OpenSUSE's Build
Service. It did take some tweaking,
mostly of package parameters like dependencies to get the tools
bootstrap going, but then 22 distros built Minix without changing
the build system itself; here are the
done NetBSD, and the Minix guys that work hard to cleanly integrate