Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Sam James <[email protected]> Wed, 12 Apr 2023 05:49:24 +0100
| Newsgroups | dev.linux.lists.distributions |
|---|---|
| Message-ID | <[email protected]> |
Bruno Haible <[email protected]> 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
(application/pgp-signature, 377 B)
-----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZDY4/F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDD1AD7BVrCTdZHM7G1l7peqYS758eW45GZDC/T52ea ydX+h4ABAPDedScQC4jyv6h9cKk1RBIt4PYtp0XbqpIUtX5KbfwK =9nU+ -----END PGP SIGNATURE-----