Zack> Now we've all had a while to recover from the long-awaited Autoconf Zack> 2.70 release, I'd like to start a conversation about where the Zack> Autotools in general might be going in the future. Clearly any future Zack> development depends on finding people who will do the work, but before Zack> we worry about that I think we might want to figure out what work we Zack> _want_ to do.
Thank you very much for writing this. Zack> Followup discussion should go to the Autoconf mailing list. I trimmed the CCs. Zack> Tarball releases produced by Autotools have a predictable, Zack> standardized (literally; it’s a key aspect of the GNU Coding Zack> Standards) interface for setting build-time options, building them, Zack> testing them, and installing them. This is maybe the biggest thing I've missed when I've had to tinker with other build systems. Zack> Automake tries very hard to generate Makefiles that will work with any Zack> Make implementation, not just GNU make, and not even just (GNU or BSD) Zack> make. Paul Eggert mentioned the Emacs experience here. For gdb we also started relying on GNU make a while ago. I have never heard a complaint about this. I imagine the BSDs simply build it with gmake. We've occasionally had to work around a GNU make bug but otherwise it's been straightforward. Some parts of the gdb tree do use Automake, but other parts do not. Based on this experience I tend to think that make portability isn't that important any more. Zack> And weak coordination with other Autotools compounds the issue. Zack> Building an Autotools-based project directly from its VCS checkout is Zack> often significantly harder than building it from a tarball release, Zack> and may involve tracking down and installing any number of unusual Zack> tools. Zack> Coordination among the Autotools is weak, even though the tools are Zack> tightly coupled to each other. Zack> Division of labor among the Autotools, and the sources of third-party Zack> macros, is ad-hoc and unclear. (Which macros should be part of Zack> Autoconf proper? Which should be part of Gnulib? Which should be part Zack> of the Autoconf Macro Archive? Which should be shipped with Automake? Zack> Which tools should autoreconf know how to run? Etc.) A couple of ideas come to mind here. One is that perhaps autoconf, automake, and libtool (but see below) should be combined into a single project. This would help eliminate the coordination problem. In the past Automake had a much quicker release cadence than Autoconf, but those days are past. Maybe this would allow for the elimination of some hacks. Maybe aclocal could go away, or be redone in some way that makes more sense. Another idea is that Autoconf should incorporate many of the third party extension macros. Similarly, GCC and GDB ship with a directory full of macros, some of which should probably just be standard. I'm not sure if this is related or not, but pkg-config always seemed both like something that would go into this general umbrella, as well as a workaround for a fundamental hole in the toolchain. Maybe this could be addressed. Zack> Libtool is notoriously slow, brittle, and difficult to modify (even Zack> worse than Autoconf proper). This is partially due to technical debt Zack> and partially due to maintaining support for completely obsolete Zack> platforms (e.g. old versions of AIX). Can it be removed? In ancient times it seemed very necessary. Any more I tend to think that the cure is worse than the disease. >> Autotools are too difficult to work on Zack> Yes indeed. On the assumption that we are stuck with shell, M4, and Zack> Perl, however, what can we do about it? FWIW, Automake is in Perl but this does not leak through to the user. So, there's some freedom in that regard. RMS asked me to rewrite it in Guile once, though I never did get around to that. The rest remains difficult though. Tom
