Dear Lazyweb: Build Insanity Stories?

Dear Lazyweb,

I’m working on a text to introduce n00bs to the open source development process.  The latest chapter: The Horror of Building Software.  (That’s a working title.  I’m not sure whether it will be the final title or not.)

One of the things I’d like to include is a good-sized list of “all the stupid things you’re likely to run into when you try to build a project from the latest version of the source code”.  Like:

  • B0rken deps
  • Mispelings in
  • The utter lack of an INSTALL file

…and so on.

I’m focusing on GNU Autotools-based projects, just because I have to start somewhere, but Ant/Maven horror stories are also fine.  What small, stupid things have cost hours of your life in a software build process?  Lemme hear ’em.  In fact, I think this might be an entertaining standalone site. or some such.


Dear Lazyweb: Build Insanity Stories?

8 thoughts on “Dear Lazyweb: Build Insanity Stories?

  1. Stephen Smoogen says:

    Things I have dealt with in the past:

    1) INSTALL is empty or wrong.
    2) configure is not used anymore.. but still there. Instead you are supposed to use (or vice versa).
    3) autoconf, automake, auto… needs to be run before you can get the software to really compile. [You usually discover this 4 hours into a build and a bunch of google searches.]
    4) software requires specific version of a library (oh it works because libc is from Debian with a patch applied).
    5) build process needs manual intervention or unmarked flag.
    6) Imake
    7) you start a cpan install and find out the next day it downloaded and installed a new perl, and a bunch of other software you had no idea about.
    8) you do your builds on your fastest box which is also your web server.. and some of the above occur.

  2. 1) The build depends on a core library, say, libdoeseverythinguseful, that the app needs to do anything useful at all, but the build process will happily let you build without. Classic examples, image editors and image loading libs, mp3 players and mp3 libs. 13 hours later you notice the “libuseful found…….no” line.

    2) docs generation. Code is all easy to build, the docs require Framemaker, troff from irix 4, and the latest version of If you want diagrams, it will require a visit from Donald Knuth and a check for $314.

    For more specific things:

    1) PKG_CONFIG_PATH is wrong or not set (usually to somewhere in /usr/local/)
    2) ldconfig need to run before the new libs that were just installed are found
    3) that configure script? you should really take a look –help before building. Unfortunately, it’s almost impossible to tell apart the “you should never ever need to change this” options from the “won’t build without this” options

  3. Casey Dahlin says:

    If they’re building against libraries that are installed from the package manager, not having the -devel package. Its a trivial, obvious thing, but it can be frustrating to the uninitiated, especially since configure reports the library as not being there at all, usually resulting in a fistfight with yum.

  4. Not being able to sudo/su to root to install packages as deps, and/or not knowing how to install packages to a user account. Of course, alot of packages make that difficult if not impossible. A lot of students seem to be in enviroments where they have limited privs and run into this.

  5. In some dists, /bin/sh is symlinked to bash. While autotools works with any posix shell, people who do fancy things in their build systems occasionally end up writing bash specific code. This results in very… interesting errors if you run one of the dists that symlinks /bin/sh to something like dash instead.

    Of course, the bsd people have been telling us for years that we’re Doin’ It Wrong, but not everyone got the message 🙂

    Another thing that frequently bites me is that the make dependency graph is broken, so if you for instance run your build over multiple CPU cores, things will just fall apart. This one may not be that common among n00bs, though, unless someone gave them “magic code to put in magic file to make builds go faster” and/or they’re Gentoo users.

  6. @Robin Sonefors: I’d blame the distros which symlink /bin/sh to crap there. 😉 Fedora users won’t have this problem as /bin/sh is bash here. 🙂

    Re Greg DeKoenigsberg’s original post: IMHO autocrap IS a build insanity story. 😉 CMake FTW! :-p

  7. * Builds that run test suites requiring root in order to bind to privileged ports to create a listener
    * Builds that run test suites that have an entirely different set of undoc’ed dep’s in order to stand up a listener for the tests to interface with
    * Builds that automatically run the aforementioned test suites without warning
    * Builds that overload / patch out / redefine core build tools with some other thing that’s not in the deplist that performs an identical task, just differently but with a “better” syntax that’s more “flexible”
    * Builds that do the above, but then fail to use the other tool correctly in a way that actually makes things better or more useful
    * Build tools that insist on downloading and installing the most recent version of its’ self at first build
    * Build tools that insist on including a copy of themselves in the resulting blob so that installation is *easy*
    * Builds that insist on having the previous version of themselves in order to build the current version, and offer no way to bootstrap
    * Builds that have deps on different versions of the same library, thus requiring all of those versions of the library to be included in the build
    * Builds that use ant so wrongly that after the build, you need to manually glue the build into a pre-existing jarfile
    * As a corollary to the above: Builds that allow for successful full builds where something didn’t actually compile correctly, but that’s ok, because we don’t need that .class file anymore because we have a functioning one already in the jarfile that we can use from our build a few years ago.
    * Builds that require the config to be set at build time so it can be integrated into the jarfile
    * Build / build promotion tools that require knowledge of some bit of data in the production environment in order to make something happen on a test/dev/staging system
    * Builds that require SCM tools in order to function correctly
    * Builds that have never been released in any actual way, everyone just pulls trunk from SCM when the developer tweets “whee! it works!”
    * Software that has no build at all, just copy-n-paste from this here web-page into your htdocs folder and then chmod 777 some directory someplace! (I believe this includes every php-based wiki ever written)
    * Builds with a version number less than 1 or have “beta”, “alpha”, or “pre” in the version but are still stated to be “production quality, paypal donations warmly accepted”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s