From: Bruno Haible <bruno@clisp.org>
To: "Zack Weinberg" <zack@owlfolio.org>,
"Pádraig Brady" <P@draigbrady.com>,
bug-gnulib@gnu.org, "Paul Eggert" <eggert@cs.ucla.edu>
Cc: Sam James <sam@gentoo.org>, distributions@lists.linux.dev
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Tue, 11 Apr 2023 00:36:45 +0200 [thread overview]
Message-ID: <9797572.lZ1qq7WqSs@nimes> (raw)
In-Reply-To: <9636462e-920f-2e6e-3d2c-ec58e43021a2@cs.ucla.edu>
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.
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.
> Similarly for AC_SYS_LARGEFILE_REQUIRED.
For the sake of symmetry between the two, that makes sense.
Bruno
next prev parent reply other threads:[~2023-04-10 22:36 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 [this message]
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
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=9797572.lZ1qq7WqSs@nimes \
--to=bruno@clisp.org \
--cc=P@draigbrady.com \
--cc=bug-gnulib@gnu.org \
--cc=distributions@lists.linux.dev \
--cc=eggert@cs.ucla.edu \
--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 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.