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.
Huzzah for Autotools! No pain, no gain.
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
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.
…no pain, no gain.
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…
How about dependencies as a standard feature?
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.
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.
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…
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.
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.”…
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 =)
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.
KDE just moved away from autotools to cmake. They also evaluated SCons, but settled on cmake in the end:
http://lwn.net/Articles/188693/