|FROM ||Bob Friesenhahn
|SUBJECT ||Re: [Hangout - NYLXS] Future plans for Autotools
|From hangout-bounces-at-nylxs.com Thu Jan 21 00:22:15 2021
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [220.127.116.11])
by mrbrklyn.com (Postfix) with ESMTP id 7B98C163FFD;
Thu, 21 Jan 2021 00:22:14 -0500 (EST)
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 88134163FE2; 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 [18.104.22.168])
by mrbrklyn.com (Postfix) with ESMTP id 1BF47163FCD
for ; Wed, 20 Jan 2021 18:32:47 -0500 (EST)
Received: from localhost ([::1]:35846 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
for ruben-at-mrbrklyn.com; Wed, 20 Jan 2021 18:32:47 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37972)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1l2Mx6-0004qV-Rl; Wed, 20 Jan 2021 18:31:53 -0500
Received: from smtp.simplesystems.org ([22.214.171.124]:53169)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1l2Mx2-0000K9-9d; Wed, 20 Jan 2021 18:31:52 -0500
Received: from scrappy.simplesystems.org (scrappy.simplesystems.org
by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id 10KNVjH1017121;
Wed, 20 Jan 2021 17:31:45 -0600 (CST)
Date: Wed, 20 Jan 2021 17:31:45 -0600 (CST)
From: Bob Friesenhahn
To: Zack Weinberg
User-Agent: Alpine 2.20 (GSO 67 2015-01-07)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(smtp.simplesystems.org [126.96.36.199]); Wed, 20 Jan 2021 17:31:45 -0600 (CST)
Received-SPF: pass client-ip=188.8.131.52;
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
Cc: Autoconf , automake-at-gnu.org
Subject: Re: [Hangout - NYLXS] Future plans for Autotools
List-Id: NYLXS Tech Talk and Politics
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
On Wed, 20 Jan 2021, Zack Weinberg wrote:
> Now we've all had a while to recover from the long-awaited Autoconf
> 2.70 release, I'd like to start a conversation about where the
> Autotools in general might be going in the future. Clearly any future
> development depends on finding people who will do the work, but before
> we worry about that I think we might want to figure out what work we
> _want_ to do.
Zack, your text was excellent and I agree with all of it.
Autotools is in great danger of becoming irrelevant, at least for new
software development. A lot of people feel hostile toward it.
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.
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. 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.
I like your idea of supporting other underlying build tools besides
'make'. Make's dependence on matching rules and file time stamps is
problematic and it does not scale. It is unfortunate that GNU
produced a much more powerful 'make' tool (a paradigm invented in
1976), but not a new build tool with fresh ideas to improve build
quality and reduce build times on modern systems.
The macro definitions provided by Autoconf have been proven by the
test of time and allow the underlying implementation to be changed.
Only surrounding shell script might need to be changed if the
underlying implementation changes.
The support for 'distcheck' is excellent.
Regardless, thanks for your ideas and the red alert.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Hangout mailing list