I (Heart) Autotools
May 17th, 2006 by 
Multimedia Mike
Oh, autotools– what would I do without you? Recognizing your utility places me in a minority. I know you are woefully underappreciated and catch a lot of flack for your apparent complexity. But this is largely because many programmers refuse to face up to the fact that the complexity of building a program is commensurate with the complexity of the program itself. They might not like you but don’t take it personally as they are invariably at a loss to produce a superior solution. You do most everything that developers need from a build system– they just need to find a decent tutorial, reference, or –best of all — another source package that implements the same feature they need; there must be thousands of examples to choose from.
Posted in Programming | 
14 Comments »
May 18th, 2006 at 2:54 pm
Huzzah for Autotools! No pain, no gain.
May 19th, 2006 at 5:29 am
I challenge you to set up and maintain an autotools setup yourself. Cheating by having somebody else do it is not allowed. Feel the pain for yourself and let’s see what you write afterwards ;-P
May 19th, 2006 at 12:06 pm
Actually, I have done it myself on several occasions. I admit it’s painful at the outset each time but pays off in the long run.
May 19th, 2006 at 6:54 pm
…no pain, no gain.
May 20th, 2006 at 9:27 am
OK, would you care to elaborate what gain you see that outweigh the bloat and slowness? What are you missing in the FFmpeg build system? Note that I’m likely to implement reasonable requests…
May 20th, 2006 at 9:50 am
How about dependencies as a standard feature?
May 20th, 2006 at 9:56 am
Elaborate, what do you mean by dependencies? BTW, I think we should take this to mail, I’m not sure this is the best medium for this type of exchange.
May 20th, 2006 at 10:26 am
Dependencies means when you modify avcodec.h, the Makefile is smart enough to know that it needs to rebuild the rest of libavcodec (because every lavc file invariably depends on avcodec.h). We can discuss the details more in email.
However, I would like to publicly address the “bloat” issue. I recently autotooled a project. When the tools were finished running, the configure script was 23,000+ lines and the main Makefile was 4300+ lines… SO? What’s the big deal? I don’t really care how big they are as long as they do what they’re supposed to do. The bloat thing seems particularly specious when one realizes that a C compiler generates hundreds or thousands of lines of ASM code to be assembled into a final binary. I don’t audit that code, either; for the most part, I trust the compiler knows what it’s doing.
May 20th, 2006 at 11:00 am
Hey, it already does, ‘make depend’ is your friend. For some reason it does not seem to get run automatically, though. That’s a bug that I’ll investigate ASAP. Thanks for pointing it out…
I don’t care (that much) about bloated autogenerated files, but I care about speed and the more bloat, the less speed. (auto)configure is dog-slow and while it runs i sit there twiddling my thumbs. I run configure *a lot* so the faster it runs the less of my life I have to watch pass by in vain ;-)
I also care about maintainability. Having black magic understood by few in the build system is not conducive to that.
Let’s move the rest to email…
May 20th, 2006 at 3:48 pm
A system that I’ve had extensive experience with is SCons, and it does all kinds of wonderful things. Writing the ffmpeg build scripts with SCons would probably take about four hours (worst case), and it calculates dependencies correctly, has auto-conf like features, etc.
Its main advantage over make (and friends), imho, is that build scripts are Python files, so you have the power of a real general-purpose language at your hands.
On the negative side, it probably won’t fly with ffmpeg devs because they’re used to make, etc.
May 21st, 2006 at 9:59 am
It would add an extra dependency to FFmpeg, which will be unwelcome.
Thanks for bringing up SCons, though, it’s the answer to Mike’s “They might not like you but don’t take it personally as they are invariably at a loss to produce a superior solution.”…
May 21st, 2006 at 10:39 am
If it were up to me though, I’d say “Yes” to SCons, since the cost of installing an extra program is negligible compared to what SCons can do to a build. I think most linux boxes these days have some sort of Python installation anyway, and SCons is just a set of Python scripts so there’s no need to compile it or anything. It’s also rather small.
I think one of the most unfortunate things with dev teams is that they’re very skeptical about many things =)
May 22nd, 2006 at 5:09 pm
True Python is often available when not installed by default on many distrib. But recently i compiled a few soft that use SCons and i quickly noticed something. It use an insane amount of memory:
5658 alban 18 0 14972 12m 2140 S 0.0 10.5 0:09.50 python
More than 10MB just to start a few gcc is really what i call pure bloat, make manage it with less than 1MB.
June 22nd, 2006 at 5:44 am
KDE just moved away from autotools to cmake. They also evaluated SCons, but settled on cmake in the end:
http://lwn.net/Articles/188693/