Jim Meyering wrote:
> in that situation it would be nice to have a way
> to ensure that the primary module list is a superset of
> those used for the tests.
In general, you don't want this. Let's take this precise example: Your program
needs 'dup2'. We decided to make a test for dup2 which happens to use 'open'.
Will you want to compile the 'open' replacement as part of lib/ therefore?
Most people will say "no":
- People will complain about the longer compile times for "make".
- People will complain if that particular gnulib module 'open' has a
portability problem. (If it's in lib/ it's compiled by "make". If
it's in gnulib-tests/ it's not compiled until "make check".)
- People creating a shared library will complain about unnecessary code
in their shared library.
> Offhand, I don't see how to obtain
> the test-induced list of modules.
When gnulib-tool's output contains lines like
lib/fcntl.in.h -> gnulib-tests/fcntl.in.h
you know that some non-tests module was in the transitive closure of the
test-induced modules.
Bruno
