[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future plans for Autotools

From: Nate Bargmann
Subject: Re: Future plans for Autotools
Date: Wed, 20 Jan 2021 19:06:53 -0600

* On 2021 20 Jan 17:33 -0600, Bob Friesenhahn wrote:
> Autotools is in great danger of becoming irrelevant, at least for new
> software development.  A lot of people feel hostile toward it.

This is quite true.

As a co-maintainer of a library project that uses Autoconf, Automake,
and Libtool, I've been asked point blank after the most recent major
release why we have not switched to cmake.  My answer was that I don't
have the time nor the desire after spending a considerable amount of
time getting my head around Autotools enough to improve and maintain the
project's build system with a modicum of sanity.  The project builds on
any POSIX platform that Autotools can support and MS Windows.
Portability of the build system is vital to this project and that is the
second priority of the build system.

I've built projects from cmake and the Qt equivalent and while their
build definition files often seem simple, it appears to me there is a
lot that goes on behind the scenes.  One strength of the Autotools is
that Autoconf and Automake are almost infinitely malleable.  Each
supports dropping shell syntax in or make syntax in a respectively.  There just simply need to be ways for the
project maintain to extend the build system in ways specific to that
project.  I've never cared to investigate cmake to know whether it is as
capable thus I am unsure if cmake trades control for simplicity.

> It seems to me that Autoconf is too difficult to work on.  There is too much
> to become expert at in order for new volunteers to make an impact.  The same
> is true for libtool.
> In my opinion, a new "language" designed specifically to meet the needs of
> Autoconf should be developed and Autoconf should be re-implemented using it.
> There should be no more need to run external utilities like 'sed', or 'awk'
> or other things which can be implemented internally in a way which does not
> suffer from the white space and delimiter issues that shell script does.

I'm not here to defend m4, on the contrary, my life would continue on
just fine if I never had to look at m4 ever again.  The very few times I
have tried have not been pleasant.  On the other hand, is there any
enthusiasm for reimplementing sed, awk, or other such utilities since
Perl did it over 30 years ago and other scripting languages have done so

The good thing about Automake is that though it is written in Perl, the
implementation language doesn't seem to bleed through into the syntax of  With Autoconf, so long as the maintainer can stick with
the provided macros or third party ones, life is tolerable.  On the rare
occasion that I started looking at enhancing a macro, I began
questioning some life choices!

On the other hand, I am not so quick to abandon shell syntax.  It is the
lowest common denominator on POSIX like systems.  That said, perhaps a
reasonable approach would be to target a somewhat older POSIX
specification and abandon support for shells that cannot reach even that
low bar.  As an aside, I have worked to ensure that any shell script
that I write is free of Bashisms even though they can make writing
scripts easier.

> It seems that the core precept that Automake should produce portable
> makefiles should be re-evaluated if most systems provide GNU make, or can
> easily be updated have it.

At the moment the project(s) that seem to be working toward replacing
all things GNU do allow the later installation of GNU software.  Will
such projects eventually become hostile to even the premise of
installing GPL software, let alone GNU software, ala iOS?  If so, my
concerns about support for other make implementations likely become moot
as the project I'm involved with is GPL/LGPL licensed.

> There is a fork of Automake which was re-done to
> be based on GNU Make. This assumes that makefiles written in GNU make can
> noticeably improve things.

What negative impact would relying solely on GNU make have on third
party projects intending to build on platforms where the installation of
GNU make may become discouraged?  While I've not read of any public
plans of such, the actions of FreeBSD make me curious if they might head
in that direction eventually.

> The support for 'distcheck' is excellent.
> Regardless, thanks for your ideas and the red alert.

Agreed on both of these counts, Bob.

- Nate


"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]