> On 10 Nov 2022, at 21:10, Michael Orlitzky <michael@xxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Message signed with OpenPGP
