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
