(Removing automake as the original message said "Followup discussion should go to the Autoconf mailing list.")
I agree that consolidating support for the current architecture and use cases is the place to start. The number one screaming priority would seem to be adding continuous integration. https://www.gnu.org/software/devel.en.html suggests that the preferred system is Hydra. New developers would almost certainly prefer gitlab or github as a hosting/CI system as opposed to Savanna + Hydra, but staying 100% free is a big gnu goal, so it's worth trying Hydra first...? - Dan On Wed, Jan 20, 2021 at 4:07 PM Andy Tai <a...@atai.org> wrote: > > It seems better not to start another language. with already lack of > resources, that will further dilate available resources, and hard to > compete with other tools already us9ng Python's mature ecosystem > > On Wed, Jan 20, 2021 at 3:32 PM Bob Friesenhahn < > bfrie...@simple.dallas.tx.us> wrote: > > > > > 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. > > -- > > Bob Friesenhahn > > >
