> On 10 Nov 2022, at 21:10, Michael Orlitzky <michael@orlitzky.com> wrote:
> 
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>> 
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
> 
> While everyone else is discussing big ideas, it would be helpful for me
> personally if autoconf just made a release with the latest bugfixes.
> 
> I report these compatibility issues upstream, and it's awkward to have
> to tell the maintainers that they must cherry-pick a git commit,
> rebuild autoconf, and then autoreconf their project before they can
> even even think about exporting CFLAGS="-Werror=..." to build-test
> their project.
> 
> 

Before I dive into the rest of this thread: yes, this is one of
my main thoughts on the matter. Autoconf has a huge network
effect problem and letting the existing fixes start to propagate
would be most helpful.

Like it or not (and I don't like it), various software tries
to jam in -Werror (and sometimes -pedantic-errors, see rsync!) to their
configure scripts which means even prototype issues end up
causing problems.

Note that in autoconf git, we've also got https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
which is going to affect time_t efforts too, but that's
for another thread on libc-alpha at some point
when I want to bring up some issues.