[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]