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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.