hierarchical projects with configure scripts (was: Re: max_align_t on RHEL 7.1 s390x)

[Bruno Haible]

Hi Sergio, all,

> I managed to reproduce this bug, and also to find the reason for it.

Thanks for explaining it!

> Basically, the gnulib machinery to identify the compiler features and
> modify its flags is working OK, as can be seen by this excerpt from
> gnulib/Makefile:
> 
>   ...
>   CC=gcc -std=gnu11
>   ...
> 
> Also, if I enter the gnulib build directory (which, for GDB, is located
> at "gdb/build-gnulib/") and run "make", everything works fine.  The
> problem happens when GDB's Makefile invokes gnulib's.  Here's how it
> works.
> 
> GDB's Makefile uses this incantation to build gnulib:
> 
>   all-lib: $(GNULIB_BUILDDIR)/Makefile
>           @$(MAKE) $(FLAGS_TO_PASS) DO=all DODIRS=$(GNULIB_BUILDDIR) subdir_do
>   .PHONY: all-lib
> 
> The "subdir_do" rule is:
> 
>   subdir_do: force
>           @for i in $(DODIRS); do \
>                   ...
>                   if [ -f ./$$i/Makefile ] ; then \
>                           if (cd ./$$i; \
>                                   $(MAKE) $(FLAGS_TO_PASS) $(DO)) ; then true 
> ; \
>                           else exit 1 ; fi ; \
>                   else true ; fi ; \
>           done
> 
> Which is correct, and should work at first glance.  However,
> FLAGS_TO_PASS contains:
> 
>   FLAGS_TO_PASS = \
>           ...
>           "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.

Other packages with separate configure scripts in subdirectories (e.g.
GNU clisp) have similar issues.

Namely, we have a conflict between
  (a) the requirement that (CC, CFLAGS) for build is the same as
      (CC, CFLAGS) for configure, in every subdirectory, and
  (b) the desire of developers to be able to rebuild an entire source
      tree with "make clean; make CFLAGS='-O0 -ggdb'" or so.

In small packages the solution can be to merge all the configure
scripts into the top-level one. This greatly reduces the configure
times as well. But this is not feasible for GNU gdb or GNU gettext.

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.

If we could redesign the GNU build system from scratch, we could
define a variable GLOBAL_CFLAGS or RECURSIVE_CFLAGS that could be passed
down by 'make'. And all Makefiles would have to use
  $(CC) $(CFLAGS) $(GLOBAL_CFLAGS)
instead of just
  $(CC) $(CFLAGS).

This would be the proper solution, but is a lot of work in the
GNU Coding Standards, in Automake, and Autoconf.

> Unless someone has a better idea, I'll propose a patch to not pass
> CC/CXX to gnulib's Makefile on GDB.

It's not only CC, CXX, but also CFLAGS, CXXFLAGS, LDFLAGS.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2017-11/msg00014.html