The Autotools are a suite of utilities including automake, autoconf, and libtool that have become the de facto standard for facilitating the building and distribution of open source software. When you get a package, unpack it, type ‘./configure; make; make install’, you are seeing the Autotools’ work in action (usually; some projects fake it). When the Linux Flash Player team inherited the Flash Player 7 code base, the build system was comprised of a series of ad-hoc Makefiles. There was room for improvement but I didn’t want to autotool the build system at first. It seemed like overkill. Plus, when I think of Autotools, I usually think of a system that facilitates source code distribution. Not necessary since Adobe isn’t open sourcing the Player at this time.
However, after some research regarding how to do some things that I really, really wanted (like proper automated dependency generation), I realized that the Autotools take care of common build system headaches. Certainly, some contend that the Autotools constitute an even larger headache. Fortunately, between the Autobook, the official manuals, and thousands of existing projects already using the tools, comprehension is within reach.
So I autotool’d the Flash Player source to facilitate building on Linux. Then I got my wish of proper dependencies which means, for better or worse, the build system knows that most source files, one way or another, depend on that one particular header file that I just modified.
It’s important to acknowledge that the Autotools really, honestly do know how to just “Do The Right Thing”. After autotool’ing the project, a few strange build idiosyncrasies and minor bugs (and at least one major bug) disappeared, having apparently been artifacts of the legacy build system. Overall, we have much more confidence in the built binaries thanks to the Autotools.
Don’t be afraid of the Autotools.