Autoconf often gets a lot of hate from developers, who think its syntax is obscure, its implementation is baroque, and in general it’s too difficult for the purportedly simple task it is asked to perform. In response to a thread on the autoconf mailing list with the subject “just one of a million reasons why autoconf is a worthless piece of shit“, I wrote this rebuttal. Hopefully it will explain why the autotools suite works the way it does, and why it’s really not over-engineered for its purpose. And, why you should consider using it even though you don’t have to love it, or even like it.
You have two misconceptions which are contributing to your frustration, I think: the first and largest one is that the goal of autotools is to make the maintainer’s life easier. As has already been stated a few times, autotools is not about the maintainer. Autotools is about the USER. In fact this is a philosophy that underlies all of GNU, starting with the GPL itself. The idea is that packages should automatically configure themselves for the user. You probably don’t remember, but back in the day building a new software package was a time-consuming and frustrating experience of reading various README and INSTALL files, editing makefiles and header files by hand, etc. It would usually take the better part of a day, or longer, and all the knowledge was unique to each package and had to be relearned every time you wanted to update it.
Now, users just run configure and make. There are standard and simple ways for them to do very complex things, and all that knowledge is applicable across a huge spectrum of free software. Even packages that don’t use autoconf quite often provide a configure script, for compatibility (and the number one complaint for those packages is that their configure script doesn’t support some particular feature that autoconf configure scripts do).
Consider the kinds of things that users of any properly autoconfigured package can and expect to be able to do:
- cross-compilation
- installation into alternate directories, either wholesale or on a very granular scale
- easily adding common prefixes or suffixes to installed targets
- support for all sorts of bizarre platforms, most of which the maintainer of the package has never heard of, much less has access to.
And, they get it all using nothing more than configure and make.
All of this capability, and most especially making it all simple for the user, comes at a cost, and that cost is complexity in autoconf and extra work for the maintainer of the package. But that’s OK, because that’s the design philosophy we are committed to. We don’t see complaints from users about how hard it is to work with autoconfigured packages (quite the contrary!), and to us that means we’re doing a good job achieving our most important goal.
The second misconception is that you can greatly simplify package configuration by targeting what you call “the real world”, implying that autoconf spends too much effort on obscure capabilities that no one really uses. In fact, autoconf deals with the real “real world”, where people have systems with strange characteristics and they still want to compile free software for them. We want to support that, because our ultimate aim is to promote the use of free software. The world that your “simple” solutions work for is an idealized one where everything is tidy and perfect and no one wants to do anything out of the ordinary. That world only exists in test environments.
If you release your software with your configuration environment, and it gets at all popular, I will bet that you will get countless requests to add support for lots of features and abilities that autoconf packages already have, along with reports of problems building and/or installing on machines autoconf already supports. And by the time you get done handling all this you will have spent MORE time and effort on it than you would have if you’d just used autoconf, AND your environment will be less portable, more brittle, and frustratingly (for your users) non-standard.
Cheers!