Re: select self-tests causes build failures under mingw

[Simon Josefsson]

Paolo Bonzini <address@hidden> writes:

> Simon Josefsson wrote:
>> Paolo Bonzini <address@hidden> 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