Paul Eggert wrote: > The problem I ran into first was surprise on the developer's part: why > is Gnulib pulling in all this stuff I'm not using?
Yes, I see how this is a psychological problem. > Part of this issue here is, how much do we want to cover all > theoretically-possible issues, versus how much do we want to support the > likely practical uses? For example, although POSIX *allows* an app to > include <sys/shm.h> merely to define time_t, this is pretty unlikely and > I think we needn't worry about that. Yes, this is the core of the question. The <config.h> reminders that we already have added catch maybe 95% of the mistakes. With the added module dependencies I tried to bump this percentage to maybe 98%. But maybe 95% is good enough after all, since the attempts to go towards 100% either surprise our users or add complexity to the documentation. I'm thus reverting the dependency additions. > Perhaps we should have the shmctl module depend on > year2038 instead? Indeed, that sounds right, and is also the approach we used with the 'largefile' module. Basically everything that can call open() or stat() has a dependency to 'largefile'. But first, I suggest, we should get the Autoconf support for year2038 right. Then we can revisit the functions one-by-one, based on https://sourceware.org/glibc/wiki/Y2038ProofnessDesign . 2023-04-16 Bruno Haible <br...@clisp.org> year2038: Revert the added module dependencies. Suggested by Paul Eggert in <https://lists.gnu.org/archive/html/bug-gnulib/2023-04/msg00117.html>. * modules/year2038 (Depends-on): Remove sched, sys_msg, sys_select, sys_sem, sys_shm, sys_stat, sys_time, sys_types, time-h, utime-h. diff --git a/modules/year2038 b/modules/year2038 index 7a7b5d4eb5..c44d4dc868 100644 --- a/modules/year2038 +++ b/modules/year2038 @@ -10,20 +10,12 @@ Files: Depends-on: largefile -sched -sys_msg -sys_select -sys_sem -sys_shm -sys_stat -sys_time -sys_types -time-h -utime-h configure.ac-early: AC_REQUIRE([AC_SYS_YEAR2038]) +configure.ac: + Makefile.am: Include:
