Re: Future plans for Autotools

[Bob Friesenhahn]

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.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt