Re: Future plans for Autotools

[David A. Wheeler]

Zack, thanks for the interesting analysis.

In the *short* term, I think “create a CI system” is the critical first step. 
Since the autotools are all about supporting many platforms, if possible that 
infrastructure should support VMs with many different targets (many Linuxes, 
MacOS, Windows, some *BSDs, etc.). I looked for something supporting FreeBSD & 
found this: https://cirrus-ci.org/ <https://cirrus-ci.org/> . I don’t know if 
it’s any good. If that’s too hard, at least create a CI system with a few 
targets. A CI system with even just a few targets would be better than nothing.

I think long delays between releases create their own problems. If a release 
was no more than a year apart, releases would be much easier & less stressful. 
A new release, even if it’s just a few bug fixes, would signal “we’re alive” & 
help people who needed those fixes.

In my mind, the key advantage of autoconf is its “check for what works” instead 
of quirk-list approach, and that end-users don’t need to install much (except a 
few Unix tools like a shell). It would be great for the autotools to have 
better Windows support.

One of the biggest set of challenges in the use of m4. To my knowledge, the 
main reason to use m4 was because some shells didn’t support shell functions. 
At this point that’s historical. I think it’d be possible to slowly rewrite 
macros as “normal calls” to functions, and over time make it possible to use 
autoconf without using m4 at all. That would however be a long-term goal, not 
something done quickly.

--- David A. Wheeler