Ryan Gonzalez writes:
I have used fbuild a LOT
Actually, I suspect that in the relevant sense, you haven't used it a lot. Have you used it for a single program on 1. more than 3 CPUs, AND 2. on each CPU, more than one (and preferably more than two) OSes, AND 3. for each CPU-OS combination, more than two different configurations of the program being built, AND 4. for each CPU-OS-configuration combination, at least 3 versions of the program source (preferably spanning a major version bump)? The number of programs/versions you have built on a single (or small selection of) CPU-OS combinations is irrelevant to the discussion. The problem autotools helps to solve better than any other system I know of is bootstrapping on a new system. It's also quite good at handling foibles (== regressions) across version bumps of the source program. I agree it's suboptimal (at best :-) to have a PyPI module that depends on the autotools. I've found it to be a real PITA for Windows users who want to develop certain Emacs Lisp applications, for example, which is a similar kind of development environment to Python. But for bootstrapping Python itself, what else is there, really? Every time I've seen a project move to something like SCons, I've also seen their port rate to new platforms decrease dramatically. (Hard to interpret that trend, though -- if a project has the free cycles to change build systems, maybe they have ported to almost all of the plausible platforms already.) Autotools alternatives just have way fewer modules for dealing with new and/or old ;-) platforms. Bright! Shiny! New! system use crufty old system :-( + => + missing library :-( library Caveat: Autotools is the only build system (well, Imake -- now you know how old I am!) I have substantial experience with. But I've heard stories from colleagues about the limitations of Scons and cmake in this respect, and I find it hard to believe that there are systems out there with the accumulated knowledge of platforms that has been assembled in Autotools over the decades.