Paolo Bonzini <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> writes: >> >>>> Maybe gnulib self-tests directories should have their own configure.ac >>>> and config.h, although I fear the build-times of having 6 CONFIG_SUBDIR >>>> statements in GnuTLS... I'd probably prefer to disable the gnulib >>>> self-tests. Even the move to 3 CONFIG_SUBDIR's causes significant >>>> slow-down. >>> You can make a script to compute the list of tested packages, and make >>> it with only 4 CONFIG_SUBDIR. >> >> I don't think so, the generated unistd.h in gl/ differ from the >> generated unistd.h in lib/gl/ because different set of gnulib modules >> are enabled for the two respective directories. The same problem likely >> holds for other header files too. Which directory should be first in >> the list of compiler -I's for the gnulib self-tests directory? > > If your main aim is to test the modules' source code rather than the > include files, you can just make another gnulib in a CONFIG_SUBDIR; it > will include all the modules in the gnulibs of the 3 other > CONFIG_SUBDIRs and it will be used just to run the tests. The other 3 > won't include the tests at all, though, so it won't cover things such as > "how does the close module behave when this other module is included, > *and* when it is not".
I think it may be simpler to simply avoid using gnulib --with-tests when importing multiple gnulib instances into one project. It doesn't really seem to work reliably. I noticed another problem with rpl_fseeko in GnuTLS today, I'll report it separately. /Simon