Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

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 »

14 Responses

  1. Cyril Says:

    Huzzah for Autotools! No pain, no gain.

  2. DonDiego Says:

    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

  3. Multimedia Mike Says:

    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.

  4. Cyril Says:

    …no pain, no gain.

  5. DonDiego Says:

    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…

  6. Multimedia Mike Says:

    How about dependencies as a standard feature?

  7. DonDiego Says:

    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.

  8. Multimedia Mike Says:

    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.

  9. DonDiego Says:

    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…

  10. Cyril Says:

    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.

  11. DonDiego Says:

    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.”…

  12. Cyril Says:

    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 =)

  13. albeu Says:

    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.

  14. DonDiego Says:

    KDE just moved away from autotools to cmake. They also evaluated SCons, but settled on cmake in the end:
    http://lwn.net/Articles/188693/