Rome wasn’t Built with Autotools
I hate autotools (autoconf, automake, and friends). I hate them with a passion! Unfortunately, the only thing worse than a project using autotools is a project not using autotools.
As a user, I love the simplicity that autotools promises, and sometimes delivers:
./configure
make
sudo make install
When it works, it’s a beautiful thing. When it doesn’t, it’s deep voodoo to fix. This is doubly true when you’re not using Linux.
As a developer… well let’s face it. Very few developers know the first thing about using autotools. Of those that do, almost none know more than the very basics necessary to copy, paste, and hack someone else’s autotools setup to mostly-successfully build their project. Developers who write elegant DRY code and would never even consider the cut, paste, and hack approach to software development, will lose all resolve when faced with learning autotools.
The result is sloppy, bloated, unintelligible configure.{ac,in} and Makefile.am files. ./configure scripts that take longer performing pointless and repetitive tests, than it takes to build the project. Even on big projects, most configure scripts are many orders of magnitude slower than they need to be, because they check everything under the sun—decades of copy, paste, and hack cruft. I recently went through a decent tutorial on autotools and made me a simple autotools setup from scratch for a simple toy project. ./configure took all of 3 seconds to run.
Clearly we need something like autotools. We need something to do the following mundane tasks automatically:
- Figure out if the dependencies are installed and what compiler flags we need to access them.
- Figure out the compilation, installation, etc. commands and flags.
- Construct a nice Makefile with the expected targets (install, clean, etc.)
- Allow the user to easily override and give hints.
So what is so hard about this? I can see why autotools turned out the way it did; it was written in shell and m4, in the dark ages, without the benefit of 20/20 hindsight, and has accumulated decades of cruft. The truly amazing thing is that autotools has done so well and is so popular—that’s a testament to something fundamentally right about autotools. So fundamentally right that in spite of all its warts it continues to be the premier build system.
There are contenders to replace it. Scons and CMake seem to be the leaders in this arena. I’ve used Scons on a large project (Ardour) and I wasn’t impressed. You have to be fluent in Python to use it effectively, you have to approach your build system as a full-blown programming problem in a general purpose language (Python). It’s quite slow, and you need Python installed to use it. It is very flexible, though.
CMake seems promising, but I was dismayed to see that its syntax is not much better than autotools, and the documentation is skimpy (unless you buy that book that’s out of print until the next edition). Still, it’s better documented than autotools, and the user experience is quite nice.
Will CMake rise to supremacy? With time, it may. I think there’s room to undercut CMake though. I think one could design a tool that is flexible yet easy to use, fills the autotools niche solidly, and isn’t all that complicated to boot. What do you think?
December 21st, 2007 at 22:51
Amen!
I have the same view on all your points. A couple other thinks I hate is when I do compile something I’d like to know what and where things get installed. Just in case, I dunno, I want to remove it. But most things instead of showing me a nice little “here’s what went where” when I say make install, instead give me about a thousand lines of completely useless info.
Along the same lines, with ‘make install’ there’s also a ‘make uninstall’. If that was available I wouldn’t need to know the above info. But almost nobody bothers to have an uninstall target.
-Kevin-
February 2nd, 2008 at 05:49
On small projects, configure is longer to execute than make!
My project need something like autotools, but it is making me crazy. I used mkproject to have a template, and then I hacked, trying to figure out or guessing how to do simple things. Man, how hard it is to install something in /etc!
I hope autotools find a replacement soon.
February 9th, 2008 at 10:54
I was forced to learn CMake, because I had* to use the Visual C++ compiler for a project under Windows (it uses Autotools under Unix).
The documentation for CMake isn’t awful, but it isn’t great either. Despite this, I didn’t struggle too much.
CMake works exactly as advertised, which is nice. My config files are also quite short.
My main gripe with CMake is that its syntax seems as if it was designed to be parsed by the C pre-processor and that it’s hard to debug the make files. However, this is also true for Autotools and my CMake files were quite short.