From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31201 invoked by alias); 31 Aug 2018 20:38:02 -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 31109 invoked by uid 89); 31 Aug 2018 20:38:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=influence, CXX_DIALECT, H*f:sk:87y3cok, H*i:sk:87h8jck X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.143.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Aug 2018 20:38:00 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway31.websitewelcome.com (Postfix) with ESMTP id B1550244B0 for ; Fri, 31 Aug 2018 15:37:58 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id vqAwfA3HtBcCXvqB1fdk3f; Fri, 31 Aug 2018 15:37:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tAS8j17d77bkOnJXFa0NVo8OoG7I97erMnpwfmZXEM0=; b=ETXz4bwVoj0uE0uJqt80sDQKHu EItXjlQa6xb78JILh0UHjrQ05WLpR1PXZuXN9ld8GDKpCGdxd7bho2iAGkumSbZsgjonFcVVfYNAS M38VI+HPwGW49jIIucfB8oi0K; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:60250 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fvqAw-001RVb-HX; Fri, 31 Aug 2018 15:37:50 -0500 From: Tom Tromey To: Sergio Durigan Junior Cc: Bruno Haible , 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> <87h8jck0eu.fsf@redhat.com> Date: Fri, 31 Aug 2018 20:38:00 -0000 In-Reply-To: <87h8jck0eu.fsf@redhat.com> (Sergio Durigan Junior's message of "Wed, 29 Aug 2018 23:18:01 -0400") Message-ID: <87lg8mz2zm.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-08/txt/msg00881.txt.bz2 >>>>> "Sergio" == Sergio Durigan Junior 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