On Tue, Sep 19, 2023 at 07:43:26PM +0200, Patrice Dumas wrote: > Hello, > > Thanks for the analysis! > > On Tue, Sep 19, 2023 at 04:22:42PM +0200, Bruno Haible wrote: > > * But you can see from the log above that no -I option is in use that > > allows the compiler to find the *installed* <unitypes.h>. > > * The 'libunistring' module puts the necessary -I options into the CPPFLAGS > > variable, as documented in > > > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring.m4;h=15702811764c2812ad5fe91c2407aff0a55603b9;hb=HEAD > > * But in build/tp/Texinfo/XS/config.status the value of the CPPFLAGS > > variable is empty. > > > > The origin of the bug is here: > > $ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null > > tp/Texinfo/XS/configure.ac:100: CPPFLAGS=$PERL_EXT_CPPFLAGS > > I think that the first one is not such an issue, as it is set quite > early, the libunistring module is called afterwards. Yet it would be > better to save and reset CPPFLAGS anyway to be cleaner here. > > > tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS > > This one will do as you say, throw away the -I options. Maybe it could > be enough to remove the three lines outside of > if test x$disable_xs != xyes; then > defining those when $disable_xs = no seems actually confusing. > > CFLAGS=$PERL_EXT_CFLAGS > CPPFLAGS=$PERL_EXT_CPPFLAGS > LDFLAGS=$PERL_EXT_LDFLAGS > > and, in addition, in the test in if test x$disable_xs != xyes; block > save and reset the variables.
This shows how using new gnulib modules can lead to problems, especially under the tp/Texinfo/XS directory. I don't know what problem the libunistring module was supposed to fix. Commit 3ded9f090 (2023-09-01) adds the module but it's not clear how or why it's used - I couldn't see anything in nearby commits. Could we not just revert adding the module and that would fix the problem?
