>>>>> "Sergio" == Sergio Durigan Junior <sergi...@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
