Re: hierarchical projects with configure scripts

[Tom Tromey <tom at tromey dot com>]

>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:

>>> "CC=$(CC)" \
>>> "CFLAGS=$(CFLAGS)" \
>>> "CXX=$(CXX)" \
>>> "CXX_DIALECT=$(CXX_DIALECT)" \
>>> "CXXFLAGS=$(CXXFLAGS)" \
>>> ...

>>> Which ends up overriding gnulib's CC/CXX variables.  That's why we don't
>>> see the "-std=gnu11" there.

>> Maybe the solution can be inspired by the line of thought Paul started
>> in [1]. Namely:
>> Define a *small* set of variables that influence the configure
>> results. Currently these are CC, CFLAGS, LDFLAGS, but not CPPFLAGS.
>> Then, can we define a set of variables that can be passed down from the
>> top-level Makefile the subordinate Makefiles?
>> These two sets of variables must be disjoint, and that is the problem
>> here, because users would like to use CFLAGS to pass optimization and
>> debugging flags down the build tree, after the configuration is complete.

Sergio> I'm still inclined to go the "easy way" and do what I proposed above:
Sergio> create a "FLAGS_TO_PASS_TO_GNULIB" which would omit the CC/CXX (and
Sergio> possibly other) variables, even if it's just to unbreak the s390x build
Sergio> (I still have a gnulib issue happening with mingw to investigate, sigh).

Historically the GNU and/or configure and/or automake rule was that
variables like CC, CXX, CFLAGS (etc) were for users.  So, following this
rule, I think it's correct for gdb to pass these to sub-configures and
sub-makes.

I haven't looked at the gnulib code here, but it seems to me that if
gnulib wants to find special compiler flags to build itself, then I
think those should be stuck into some other-named variable, not CFLAGS.
gdb does this itself as well, for example warning flags aren't added to
CXXFLAGS but some other variable.  In automake the convention is to name
these internal things AM_mumble, like AM_CFLAGS.  There's some
discussion in (info "(automake) Flag Variables Ordering")

Tom