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. I will try to come up with something. As a side note, it would have been better to have a specific variable like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not a big deal either. -- Pat