At Mozilla, our build system has a firm rule we only grudgingly violate:
explicit is better than implicit. What that means is that if we depend on a
foo and we don’t find it on the machine we’re building on, we fail
instead of silently assuming the user doesn’t want to build in support for
foo. If the user really wants that, she would need to pass in a
configure flag saying so. This means we know exactly what we’re shipping
as binaries, and users know exactly what to expect.
Once you spend a lot of time working with Mozilla code, you sometimes forget other projects don’t follow such obviously important rules. Case in point: Ruby. A default Ubuntu install builds Ruby out of the box. Of course, when you then try to do anything remotely useful:
% gem install heroku
Ruby fails with a cryptic
no such file to load -- zlib (LoadError).
Turns out Ubuntu doesn’t come with the
zlibg1 dev library, which means the
Ruby build system assumes you don’t care about zlib support and happily builds
Great, so you installed the library and built Ruby again, and
gem actually worked.
Now, you try to log in to Heroku:
% heroku login
… and Ruby fails with yet another
no such file to load -- net/https error.
At least the error message is slightly less cryptic this time, since it tells
apt-get install libopenssl-ruby. Which means you need to install the
library and rebuild Ruby a third time.
God knows how many more libraries the build system’s assumed I don’t care about.