[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
one dependency too much
From: |
Bruno Haible |
Subject: |
one dependency too much |
Date: |
Sat, 26 Dec 2009 19:59:59 +0100 |
User-agent: |
KMail/1.9.9 |
Hi,
While preparing a new libunistring release, I noticed that gnulib-tool
brought in many more files than for the last release, in particular these:
gnulib-m4/cloexec.m4
gnulib-m4/dos.m4
gnulib-m4/fcntl.m4
gnulib-m4/getdtablesize.m4
gnulib-m4/lstat.m4
gnulib-m4/pathmax.m4
gnulib-m4/stat.m4
gnulib-m4/symlink.m4
gnulib-m4/sys_stat_h.m4
gnulib-m4/time_h.m4
tests/binary-io.h
tests/cloexec.c
tests/cloexec.h
tests/fcntl.c
tests/getdtablesize.c
tests/lstat.c
tests/pathmax.h
tests/same-inode.h
tests/stat.c
tests/symlink.c
tests/sys_stat.in.h
tests/test-binary-io.c
tests/test-binary-io.sh
tests/test-cloexec.c
tests/test-fcntl-h.c
tests/test-getdtablesize.c
tests/test-lstat.c
tests/test-lstat.h
tests/test-open.h
tests/test-stat.c
tests/test-stat.h
tests/test-symlink.c
tests/test-symlink.h
tests/test-sys_stat.c
tests/test-time.c
tests/time.in.h
This is quite surprising, because libunistring does not make a single libc
call that deals with files or file descriptors. I don't really want
libunistring's "make check" to be sensitive to lstat, binary-io, and cloexec
issues.
It is due to a single dependency too much, that triggers an avalanche of
imports due to other dependencies. Namely,
libunistring includes unistdio/ulc-fprintf, unistdio/ulc-vfprintf.
|
+-- unistdio/ulc-fprintf depends on fseterr.
|
+-- fseterr depends on dup2.
|
+-- dup2-tests depends on binary-io, cloexec, open.
|
+-- cloexec depends on fcntl.
| |
| +-- fcntl-tests depends on getdtablesize.
|
+-- open depends on stat
| |
| +-- stat-tests depends on symlink, same-inode
|
+-- open-tests depends on symlink
|
+-- symlink depends on lstat
For my feeling, there are too many dependencies here.
* fseterr does not need dup2, because
1. the call to dup2 is in a piece of code that is disabled with #if 0,
2. even if it was enabled, it would be immune to the dup2 portability
pitfalls currently mentioned in doc/posix/functions/dup2.texi.
* The dependency of dup2-tests on 'cloexec' could be removed if the
relevant (small) part of the test would be enclosed in
#ifdef GNULIB_CLOEXEC
so that it is skipped if the cloexec module is not present. coreutils
does include the 'cloexec' module, therefore at least the coreutils users
will still have a 100% check of dup2.
* The dependency of dup2-tests on 'open' can safely be removed because the
file to be opened is "test-dup2.tmp", which does not trigger any of the
problems listed in doc/posix-functions/open.texi.
I'm handling the first part, by removing the dependency of fseterr, since
that's the most obviously redundant one.
2009-12-26 Bruno Haible <address@hidden>
Remove an unneeded dependency.
* modules/fseterr (Depends-on): Remove dup2.
*** modules/fseterr.orig Sat Dec 26 19:57:41 2009
--- modules/fseterr Sat Dec 26 19:12:26 2009
***************
*** 7,13 ****
lib/stdio-impl.h
Depends-on:
- dup2
configure.ac:
--- 7,12 ----
- one dependency too much,
Bruno Haible <=