MESSAGE
| DATE | 2021-01-20 |
| FROM | Bob Friesenhahn
|
| SUBJECT | Re: [Hangout - NYLXS] Future plans for Autotools
|
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-at-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
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
