Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Sam James]

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

signature.asc
Description: PGP signature