Since April 2021, several gnulib-tool invocations are supported in the
scope of the same configure.ac.
But there's a limitation to that: It does not really work well with
compilers that don't support #include_next (such as MSVC). Namely,
let's look what happens if there are two gnulib-tool invocations
gnulib-tool --source-base=dir1 ...
gnulib-tool --source-base=dir2 ...
Assume that in dir1, there is an override of function A in <stdlib.h>,
and that in dir2, there is an override of function B in <stdlib.h>.
Code that uses both dir1 and dir2 will be compiled with options
-Idir1 -Idir2
or
-Idir2 -Idir1
On platforms which support #include_next, the files dir1/stdlib.h and
dir2/stdlib.h will enhance each other, that is, both overrides of A and B
will become active. Whereas on platforms without #include_next:
* Options '-Idir1 -Idir2' activate dir1/stdlib.h, and dir2/stdlib.h
is ignored.
* Options '-Idir2 -Idir1' activate dir2/stdlib.h, and dir1/stdlib.h
is ignored.
Fortunately this limitation is not encountered frequently. But nevertheless,
we need to remember that two different generated stdlib.h files can lead
to trouble, and likewise for any other Gnulib-generated .h file.
I don't see an easy fix.
Bruno
