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 library 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 --disable-foo 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 without it.

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 you to 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.