Re: Future plans for Autotools

[Tom Tromey]

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