Re: Future plans for Autotools

[John Calcote]

On Thu, Jan 21, 2021 at 4:09 PM Tom Tromey <tom@tromey.com> 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