On Thu, Jan 21, 2021 at 4:09 PM Tom Tromey <tom@xxxxxxxxxx> wrote: > 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. > I personally love the idea of combining the projects so we no longer have these inter-project release issues, and so we can get more cross-project features in place with less in-fighting - or more to what really happens: less just plain ignoring requests that involve other projects because of lack of control or ego issues. I also like the idea of moving to GNU make. I feel like we'd be able to do a lot of stream- lining with such a change - removing old crufty stuff designed only to service standard make deficiencies. Another good reason for this was also mentioned earlier - the make code that automake generates could be much more efficient and performant. John
