From: Sam James <sam@gentoo.org>
To: Bruno Haible <bruno@clisp.org>
Cc: "Zack Weinberg" <zack@owlfolio.org>,
"Pádraig Brady" <P@draigbrady.com>,
bug-gnulib@gnu.org, "Paul Eggert" <eggert@cs.ucla.edu>,
distributions@lists.linux.dev
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Wed, 12 Apr 2023 05:49:24 +0100 [thread overview]
Message-ID: <87jzyhem84.fsf@gentoo.org> (raw)
In-Reply-To: <9797572.lZ1qq7WqSs@nimes>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
Bruno Haible <bruno@clisp.org> writes:
> Paul Eggert wrote:
>> > How about a middle ground between the two macros? A macro, say
>> > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
>> > - like AC_SYS_YEAR2038, has the option --disable-year2038,
>> > - like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
>> > unavailable and --disable-year2038 was not specified.
>>
>> Even simpler, let's have just one new macro instead of two. I.e., let's
>> change Autoconf to remove AC_SYS_YEAR2038_REQUIRED and to define instead
>> a macro AC_SYS_YEAR2038_OPT_OUT that acts like AC_SYS_YEAR2038 except it
>> errors out if wide time_t and --disable-year2038 are both missing.
>>
>> Then let's propagate this change into Gnulib, and rename Gnulib's
>> year2030-required module to year2038-opt-out.
>
> I like this. Thanks.
Thanks for bringing this up Bruno. This is a reasonable compromise to me
- not just in the change here, but in the documentation/phrasing tweak
as I was concerned about the rather forthright recommendation & presentation of
year2038-required.
>
> And if the package would very much like to assume a wide time_t and
> therefore has some test suite failures if --disable-year2038 was specified,
> so be it. It's better to be able to build a package at all, with some
> test suite failures, than not being able to build it at all.
>
I feel on the fence about this bit: I think it's reasonable to provide
a macro to require it as a last resort for people, but on the other
hand, providing it might be seen to encourage it as a reasonable
solution, when in most cases, it's not that way at all,
so I'll go with however the majority feels on that.
>> Similarly for AC_SYS_LARGEFILE_REQUIRED.
... and this.
>
> For the sake of symmetry between the two, that makes sense.
>
Thanks Paul as well.
best,
sam
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]
prev parent reply other threads:[~2023-04-12 5:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 13:40 recommending AC_SYS_YEAR2038_REQUIRED ? Bruno Haible
2023-04-10 14:12 ` Pádraig Brady
2023-04-10 19:09 ` Zack Weinberg
2023-04-10 19:45 ` Bruno Haible
2023-04-10 19:52 ` Paul Eggert
2023-04-10 21:08 ` Bruno Haible
2023-04-10 22:01 ` Paul Eggert
2023-04-10 21:42 ` Bruno Haible
2023-04-10 22:00 ` Paul Eggert
2023-04-10 22:36 ` Bruno Haible
2023-04-10 23:00 ` Paul Eggert
2023-04-12 0:10 ` Zack Weinberg
2023-04-19 21:23 ` Paul Eggert
2023-04-19 22:53 ` Zack Weinberg
2023-04-12 4:49 ` Sam James [this message]
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=87jzyhem84.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=P@draigbrady.com \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=distributions@lists.linux.dev \
--cc=eggert@cs.ucla.edu \
--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