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: Mon, 10 Apr 2023 23:42:48 +0200 [thread overview]
Message-ID: <5343648.xEiunlC7Kx@nimes> (raw)
In-Reply-To: <c87cc7dd-4eb8-49a1-e27e-b5621909b617@cs.ucla.edu>
Paul,
Here's a suggestion for a compromise.
Recall that the macro AC_SYS_YEAR2038_REQUIRED is like AC_SYS_YEAR2038,
with two modifications:
- It causes configure to fail if a large 'time_t' is unavailable,
- It removes the configure option --disable-year2038.
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.
It would force the packager to pass --disable-year2038 if he
accepts the year-2038 problems.
It would not require additional documentation.
That would be OK with me.
Would it be OK with you?
Bruno
(*) Feel free to find a better name.
next prev parent reply other threads:[~2023-04-10 21:42 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 [this message]
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
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=5343648.xEiunlC7Kx@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.