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

[John W. Eaton]

First, thanks for working on the new --automake-subdir feature.  We've 
been wanting to use a non-recursive build of gnulib with Octave for many 
years but have never been able to make it work completely with the 
previous non-recursive-gnulib-prefix-hack module.

For the following, I updated to

commit a2735049fd84b3ec0cae33c020459995cc7e678f (HEAD, origin/master, 
origin/HEAD)
Author: Pádraig Brady <P@draigBrady.com>
Date:   Mon Mar 7 14:04:53 2022 +0000

    fcntl-h: add AT_NO_AUTOMOUNT

    * lib/fcntl.in.h: Define AT_NO_AUTOMOUNT to 0 where not defined.
    This is available on Linux since 2.6.38.

and I'm using  use "libgnu" as the name of the gnulib build directory as 
we do in the Octave Makefile.

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:

.c.lo:
        $(AM_V_CC)depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
        $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
        $(am__mv) $$depbase.Tpo $$depbase.Plo

with

LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
        $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
        $(AM_CFLAGS) $(CFLAGS)

and that rule does not (and should not) include library-specific FLAGS 
variables like libgnu_libgnu_la_CPPFLAGS.

How can we get libgnu/libgnu_la-mktime.lo as a dependency of 
libgnu/libgnu.la instead of libgnu/mktime.lo?

I'm guessing that the problem is related to placing some objects like 
mktime.lo in EXTRA_libgnu_libgnu_la_SOURCES instead of 
libgnu_libgnu_la_SOURCES and automake is not processing the EXTRA list 
as dependencies of libgnu/libgnu.la?

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.

jwe