[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf
Subject:    Re: Future plans for Autotools
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2021-01-25 15:29:36
Message-ID: B1B8310A-BF45-42D4-920B-76B01813EAA9 () dwheeler ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]