From: Paul Eggert <eggert@cs.ucla.edu>
To: Sam James <sam@gentoo.org>, Zack Weinberg <zack@owlfolio.org>
Cc: Michael Orlitzky <michael@orlitzky.com>,
Autoconf Development <autoconf@gnu.org>,
c-std-porting@lists.linux.dev, GCC Development <gcc@gcc.gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Fri, 11 Nov 2022 16:53:57 -0800 [thread overview]
Message-ID: <288fe53e-c58c-c179-0ead-65b4df321537@cs.ucla.edu> (raw)
In-Reply-To: <66E0EB7B-1296-4442-B3A7-6811FD68290D@gentoo.org>
On 2022-11-11 15:25, Sam James wrote:
> 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?
I'm hesitant to do that partly because the changes to _TIME_BITS are
already released in multiple packages and need to be dealt with,
regardless of whether they're backed out of Autoconf. This is because
they've been in Gnulib since July and several packages based on these
Gnulib changes have been released since then. Current Gnulib assumes
these changes will appear in the next Autoconf release; if that's not
true, we'll need to upgrade Gnulib and in the meantime the other
packages released since July would still have the changes whatever we do
with Gnulib and/or Autoconf.
Since distros need to deal with the issue anyway, regardless of what
Autoconf and/or Gnulib does, I don't see why backing the changes out of
Autoconf will help all that much.
It should pretty easy for a distro to say "hold on, I don't want 64-bit
time_t yet" without changing either Autoconf or Gnulib so if you want to
go that route please feel free to do so.
next prev parent reply other threads:[~2022-11-12 0:54 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 17:16 Zack Weinberg
2022-11-10 17:52 ` Nick Bowler
2022-11-10 17:58 ` Jonathan Wakely
2022-11-10 18:12 ` Jonathan Wakely
2022-11-10 18:44 ` Aaron Ballman
2022-11-12 2:56 ` Zack Weinberg
2022-11-10 18:05 ` Rich Felker
2022-11-10 21:44 ` Florian Weimer
2022-11-12 3:22 ` Zack Weinberg
2022-11-10 18:08 ` Florian Weimer
2022-11-12 3:40 ` Zack Weinberg
2022-11-12 3:43 ` Sam James
2022-11-12 14:27 ` Zack Weinberg
2022-11-12 3:45 ` Joseph Myers
2022-11-12 15:59 ` Wookey
2022-11-12 16:12 ` Zack Weinberg
2022-11-10 18:19 ` Aaron Ballman
2022-11-10 21:05 ` Paul Eggert
2022-11-11 15:11 ` Aaron Ballman
2022-11-13 0:43 ` Paul Eggert
2022-11-14 12:41 ` Aaron Ballman
2022-11-14 18:14 ` Paul Eggert
2022-11-14 18:30 ` Florian Weimer
2022-11-14 18:35 ` Aaron Ballman
2022-11-15 14:50 ` Jonathan Wakely
2022-11-15 19:08 ` Paul Eggert
2022-11-15 19:27 ` Jonathan Wakely
2022-11-15 20:27 ` Paul Eggert
2022-11-15 20:57 ` Aaron Ballman
2022-11-15 23:09 ` Paul Eggert
2022-11-15 23:43 ` Ben Boeckel
2022-11-16 14:26 ` Michael Matz
2022-11-16 14:40 ` Alexander Monakov
2022-11-16 15:01 ` Michael Matz
2022-11-16 15:27 ` Richard Biener
2022-11-16 15:35 ` Sam James
2022-11-16 15:59 ` Michael Matz
2022-11-16 16:20 ` Jonathan Wakely
2022-11-16 16:34 ` Michael Matz
2022-11-16 16:46 ` Jonathan Wakely
2022-11-16 18:17 ` Paul Eggert
2022-11-16 18:40 ` Jeffrey Walton
2022-11-17 18:45 ` Paul Eggert
2022-11-16 18:59 ` Zack Weinberg
2022-11-17 18:58 ` Paul Eggert
2022-11-17 21:35 ` Bruno Haible
2022-11-17 22:27 ` Paul Eggert
2022-11-17 13:30 ` Michael Matz
2022-11-15 20:36 ` Aaron Ballman
2022-11-15 5:03 ` Sam James
2022-11-15 13:30 ` Zack Weinberg
2022-11-15 13:34 ` Sam James
2022-11-16 0:08 ` Bob Friesenhahn
2022-11-13 0:43 ` Paul Eggert
2022-11-17 13:57 ` Jason Merrill
2022-11-10 20:19 ` Paul Eggert
[not found] ` <d785b19371e8419f5a5817d7cdb429db91614a3a.camel@orlitzky.com>
2022-11-11 3:08 ` Sam James
2022-11-11 3:33 ` Zack Weinberg
2022-11-11 8:40 ` Sam James
2022-11-11 9:02 ` Paul Eggert
2022-11-12 14:09 ` Zack Weinberg
2022-11-11 23:25 ` Sam James
2022-11-12 0:53 ` Paul Eggert [this message]
2022-11-12 4:00 ` Sam James
2022-11-11 9:15 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=288fe53e-c58c-c179-0ead-65b4df321537@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=autoconf@gnu.org \
--cc=c-std-porting@lists.linux.dev \
--cc=gcc@gcc.gnu.org \
--cc=michael@orlitzky.com \
--cc=sam@gentoo.org \
--cc=zack@owlfolio.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).