[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John W. Eaton
Subject: Problem using library-specific CPPFLAGS with new --automake-subdir option
Date: Tue, 8 Mar 2022 10:09:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0

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:

        $(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


        $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
        $(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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]