Re: How can Autoconf help with the transition to stricter compilation defaults?

Sam James <[email protected]> Fri, 11 Nov 2022 23:25:02 +0000

Newsgroups	dev.linux.lists.c-std-porting
Message-ID	<[email protected]>


> On 11 Nov 2022, at 03:33, Zack Weinberg <[email protected]> wrote:
> 
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky <[email protected]> wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the latest bugfixes.
>> 
>> 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.
> 
> It would be relatively easy for me to take a couple hours this weekend and put out a 2.72 release with everything that's already in trunk and nothing else.  Anyone have reasons I _shouldn't_ do that?
> 
>> 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
> 
> I have not been following the y2038 work closely.  Is it going to affect things in a good way or a bad way??
> 

Back to the original thread: I suspect it might be a better idea to (temporarily) revert the two changes
and omit it from 2.72 to allow the other changes to get out.

That's not a judgement on whether the changes will ultimately remain in autoconf, I'm just
hesitant to allow a discussion I've kicked off to derail something that we were planning
on doing anyway.

What do you think?

signature.asc (application/pgp-signature, 358 B)