|FROM ||Nate Bargmann
|SUBJECT ||Re: [Hangout - NYLXS] Future plans for Autotools
|From hangout-bounces-at-nylxs.com Thu Jan 21 00:22:06 2021
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [18.104.22.168])
by mrbrklyn.com (Postfix) with ESMTP id 13472163FD6;
Thu, 21 Jan 2021 00:22:06 -0500 (EST)
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 16095163F5D; Thu, 21 Jan 2021 00:21:45 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Thu, 21 Jan 2021 00:21:45 -0500
Received: from lists.gnu.org (lists.gnu.org [22.214.171.124])
by mrbrklyn.com (Postfix) with ESMTP id B5C9F163FCD
for ; Wed, 20 Jan 2021 20:07:41 -0500 (EST)
Received: from localhost ([::1]:60678 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
for ruben-at-mrbrklyn.com; Wed, 20 Jan 2021 20:07:40 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:55692)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1l2ORG-0003LS-Ud; Wed, 20 Jan 2021 20:07:07 -0500
Received: from www11.qth.com ([126.96.36.199]:51468)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1l2ORB-0007wV-RB; Wed, 20 Jan 2021 20:07:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=n0nb.us;
Received: from [188.8.131.52] (port=40424 helo=merlin.lan)
by www11.qth.com with esmtpsa (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93)
id 1l2OR4-006CZy-1a; Wed, 20 Jan 2021 19:06:54 -0600
Received: from nate by merlin.lan with local (Exim 4.94)
id 1l2OR3-001IMt-DD; Wed, 20 Jan 2021 19:06:53 -0600
Date: Wed, 20 Jan 2021 19:06:53 -0600
From: Nate Bargmann
To: Autoconf , automake-at-gnu.org
X-Operating-System: Linux 5.10.0-1-amd64 x86_64
Organization: Amateur Radio!
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - www11.qth.com
X-AntiAbuse: Original Domain - gnu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - n0nb.us
X-Get-Message-Sender-Via: www11.qth.com: authenticated_id: n0nb-at-n0nb.us
X-Authenticated-Sender: www11.qth.com: n0nb-at-n0nb.us
Received-SPF: pass client-ip=184.108.40.206; envelope-from=n0nb-at-n0nb.us;
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
Subject: Re: [Hangout - NYLXS] Future plans for Autotools
List-Id: NYLXS Tech Talk and Politics
Content-Type: multipart/mixed; boundary="===============2008291377=="
Content-Type: multipart/signed; micalg=pgp-sha512;
Content-Type: text/plain; charset=us-ascii
* 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 configure.ac or make syntax in a
Makefile.am 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 m=
> to become expert at in order for new volunteers to make an impact. The s=
> 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 =
> There should be no more need to run external utilities like 'sed', or 'aw=
> or other things which can be implemented internally in a way which does n=
> 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
Makefile.am. 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
> 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.
"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
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset="us-ascii"
Hangout mailing list