Re: Problem using library-specific CPPFLAGS with new --automake-subdir option

[Bruno Haible]

Hi John,

> In the Octave sources, we limit the direct use of gnulib header files to 
> one convenience library so we add
> 
>    -Ilibgnu -I$(srcdir)/libgnu
> 
> to one library-specific CPPFLAGS variable, 
> %canon_reldir%_libwrappers_la_CPPFLAGS.  We don't want to add them to 
> AM_CPPFLAGS and have them used in every rule for compiling source files, 
> so instead of doing that, I used
> 
>    libgnu_libgnu_la_CPPFLAGS = -Ilibgnu -I$(srcdir)/libgnu
> 
> This setting almost works but I ran into failures when compiling some 
> object files (gnulib headers not found).  For example, compiling 
> mktime.c failed.  The generated Makefile includes the following rule 
> that uses $(libgnu_libgnu_la_CPPFLAGS):
> 
> libgnu/libgnu_la-mktime.lo: libgnu/mktime.c
>       $(AM_V_CC)$(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) 
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) 
> $(INCLUDES) $(libgnu_libgnu_la_CPPFLAGS) $(CPPFLAGS) 
> $(libgnu_libgnu_la_CFLAGS) $(CFLAGS) -MT libgnu/libgnu_la-mktime.lo -MD 
> -MP -MF libgnu/$(DEPDIR)/libgnu_la-mktime.Tpo -c -o 
> libgnu/libgnu_la-mktime.lo `test -f 'libgnu/mktime.c' || echo 
> '$(srcdir)/'`libgnu/mktime.c
>       $(AM_V_at)$(am__mv) libgnu/$(DEPDIR)/libgnu_la-mktime.Tpo 
> libgnu/$(DEPDIR)/libgnu_la-mktime.Plo
> 
> However, this rule is not used because libgnu/libgnu_la-mktime.lo does 
> not appear as a dependency of libgnu/libgnu.la.  Instead, 
> libgnu/mktime.lo appears in the gl_LTLIBOBJS list that is ultimately a 
> dependency of libgnu/libgnu.la.  Because of that, it seems that the
> .c.lo suffix rule is used instead:

It seems like the problem you are hitting is the same that was partially
solved in <https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00078.html>.

Unfortunately, as written there, it's solved only to 90%. The 'mktime' module,
for example, still contains an AC_LIBOBJ invocation, which leads to an entry
in $(gl_LTLIBOBJS).

The last 10% will/would be more work than the first 90%.

> BTW, it appears that the same thing happens when using a recursive 
> Makefile for gnulib but I didn't notice it because when the compile 
> rules are executed in the sub-make, the definition of 
> $(DEFAULT_INCLUDES) does the right thing and is limited to the libgnu 
> directory because of using a recursive Makefile.

So, it appears that your two goals — a non-recursive Makefile structure
and good isolation of the different directories from each other — are
contradictory. You can get one of them, but not both.

Bruno