Re: Future plans for Autotools

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

 



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@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux