From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110551 invoked by alias); 30 Aug 2018 03:18:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 110537 invoked by uid 89); 30 Aug 2018 03:18:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=influence, inspired X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Aug 2018 03:18:05 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCF9340216E8; Thu, 30 Aug 2018 03:18:02 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8CE942027058; Thu, 30 Aug 2018 03:18:02 +0000 (UTC) From: Sergio Durigan Junior To: Bruno Haible Cc: Paul Eggert , bug-gnulib@gnu.org, gdb-patches@sourceware.org Subject: Re: hierarchical projects with configure scripts References: <87lg8pm4li.fsf@redhat.com> <2805333.pL1CPYTu1R@omega> <87y3cokaai.fsf@redhat.com> <2373646.KA5HVAegPz@omega> Date: Thu, 30 Aug 2018 03:18:00 -0000 In-Reply-To: <2373646.KA5HVAegPz@omega> (Bruno Haible's message of "Thu, 30 Aug 2018 03:31:56 +0200") Message-ID: <87h8jck0eu.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00814.txt.bz2 [ Adding gdb-patches since this is an issue with GDB's Makefile as well. ] On Wednesday, August 29 2018, Bruno Haible wrote: > 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. Bruno, Thanks for the further explanation and for proposing a solution. I'm including the rest of the GDB developers in this discussion because this involves tweaking our build system, so I'd like more people to be able to give opinions here. I'm still inclined to go the "easy way" and do what I proposed above: create a "FLAGS_TO_PASS_TO_GNULIB" which would omit the CC/CXX (and possibly other) variables, even if it's just to unbreak the s390x build (I still have a gnulib issue happening with mingw to investigate, sigh). > 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. Right. In our specific case, I think just omitting CC/CXX would be enough (the "c99" module doesn't seem to affect other variables). > Bruno > > [1] https://lists.gnu.org/archive/html/bug-gnulib/2017-11/msg00014.html Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/