From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id CF6093858C2C for ; Tue, 28 Sep 2021 08:45:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF6093858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wm1-x32c.google.com with SMTP id l18-20020a05600c4f1200b002f8cf606262so1516604wmq.1 for ; Tue, 28 Sep 2021 01:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NOUDRsVmySwo7oySLotNnkuyIOyHF+tyJG14nFeIQKM=; b=cMSpMmyje7qXJDh1DiDUC/Nv1XgHp1wy/X9oTO5K6RBTFpv+em3wTF+JpumOkrtCgB 0DZocSmqD51hCZ335BKqEg/PSwTcjVJCoWXDJug5dNWKIv5tlcnnxgLqFKEqLyzsU5Cs 2r8/kLZMr+x1jBzv8ZEyZbRIjWYLHG0rLhNwQPxCxVHeaAB8IyqlYxvzWLKfbVpuDceN JVgshTKSchBfbuUQCmH1Dhs/pSn0FxSz3ofPhkSm8V6SQ1oJ2jQbvlF4X3eJVJnVmh5v s7OqKDi09AA4xZp0POp2yW6vvKDdmm6VsBruVeZS4w3UTzMvc609r6YvCx257FoMR0Rq b+wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NOUDRsVmySwo7oySLotNnkuyIOyHF+tyJG14nFeIQKM=; b=3SRF0DH4w/rlGV8uomZij3ORqpELY73MfqWotQipUHNrweUWpjPQG2F4y87gkmVk7/ rAHV6gU5i5ZYsDqENgiYWK8SfY2P6eWFY9/FFneul4xPn846GIt9xSYZKmmmD3FhXX13 acIlEyFG7GNCpoRaUNW8vv4q276ndIAH5Fjizh3gY0MJhvIJ5/vbsu/Elzs4xZEMjZXg 5LVnrJ9SLw2ziKhlKVH24AXiwuWis+IvRtCwns8LDy6OqpjpORCvUE8yfMt9O8G9alLQ 1eISKHhAhq88HPaK1wHHTqQiQ4Ck+gKD/5d+nPVqLbnHnGHzmz8uYOI4b9mbewXA/bVe +O8A== X-Gm-Message-State: AOAM530p2rRH7+MNa7Vmjb4Ir/CRTzwH8VZwTczBNjMAeL0ai6g5yzG0 asLtQOZJ2lvtkDSf06xnuGIKnfiP9KjEKg== X-Google-Smtp-Source: ABdhPJyZEj/SORm/lO3l0A2kKNnT6Q42ICSs+IXjaEc6A1aml5+RGN211WClQUBfgIn+d0TLxiZ+Wg== X-Received: by 2002:a1c:9dc7:: with SMTP id g190mr3606822wme.120.1632818719474; Tue, 28 Sep 2021 01:45:19 -0700 (PDT) Received: from localhost (host86-169-137-11.range86-169.btcentralplus.com. [86.169.137.11]) by smtp.gmail.com with ESMTPSA id m5sm718809wms.41.2021.09.28.01.45.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 01:45:18 -0700 (PDT) Date: Tue, 28 Sep 2021 09:45:17 +0100 From: Andrew Burgess To: GCC Patches Subject: Re: [PATCHv2] top-level configure: setup target_configdirs based on repository Message-ID: <20210928084517.GD2435280@embecosm.com> References: <20210922153042.3491108-1-andrew.burgess@embecosm.com> <87tuibskri.fsf@euler.schwinge.homeip.net> <20210924103434.GB2435280@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:44:34 up 8 days, 23:53, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 08:45:25 -0000 * Richard Biener [2021-09-27 10:23:50 +0200]: > On Fri, Sep 24, 2021 at 12:34 PM Andrew Burgess > wrote: > > > > * Thomas Schwinge [2021-09-23 11:29:05 +0200]: > > > > > Hi! > > > > > > I only had a curious look here; hope that's still useful. > > > > > > On 2021-09-22T16:30:42+0100, Andrew Burgess wrote: > > > > The top-level configure script is shared between the gcc repository > > > > and the binutils-gdb repository. > > > > > > > > The target_configdirs variable in the configure.ac script, defines > > > > sub-directories that contain components that should be built for the > > > > target using the target tools. > > > > > > > > Some components, e.g. zlib, are built as both host and target > > > > libraries. > > > > > > > > This causes problems for binutils-gdb. If we run 'make all' in the > > > > binutils-gdb repository we end up trying to build a target version of > > > > the zlib library, which requires the target compiler be available. > > > > Often the target compiler isn't immediately available, and so the > > > > build fails. > > > > > > I did wonder: shouldn't normally these target libraries be masked out via > > > 'noconfigdirs' (see 'Handle --disable- generically' section), > > > via 'enable_[...]' being set to 'no'? But I think I now see the problem > > > here: the 'enable_[...]' variables guard both the host and target library > > > build! (... if I'm quickly understanding that correctly...) > > > > > > ... and you do need the host zlib, thus '$enable_zlib != no'. > > > > > > > The problem with zlib impacted a previous attempt to synchronise the > > > > top-level configure scripts from gcc to binutils-gdb, see this thread: > > > > > > > > https://sourceware.org/pipermail/binutils/2019-May/107094.html > > > > > > > > And I'm in the process of importing libbacktrace in to binutils-gdb, > > > > which is also a host and target library, and triggers the same issues. > > > > > > > > I believe that for binutils-gdb, at least at the moment, there are no > > > > target libraries that we need to build. > > > > > > > > My proposal then is to make the value of target_libraries change based > > > > on which repository we are building in. Specifically, if the source > > > > tree has a gcc/ directory then we should set the target_libraries > > > > variable, otherwise this variable is left entry. > > > > > > > > I think that if someone tries to create a single unified tree (gcc + > > > > binutils-gdb in a single source tree) and then build, this change will > > > > not have a negative impact, the tree still has gcc/ so we'd expect the > > > > target compiler to be built, which means building the target_libraries > > > > should work just fine. > > > > > > > > However, if the source tree lacks gcc/ then we assume the target > > > > compiler isn't built/available, and so target_libraries shouldn't be > > > > built. > > > > > > > > There is already precedent within configure.ac for check on the > > > > existence of gcc/ in the source tree, see the handling of > > > > -enable-werror around line 3658. > > > > > > (I understand that one to just guard the 'cat $srcdir/gcc/DEV-PHASE', > > > tough.) > > > > > > > I've tested a build of gcc on x86-64, and the same set of target > > > > libraries still seem to get built. On binutils-gdb this change > > > > resolves the issues with 'make all'. > > > > > > > > Any thoughts? > > > > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -180,9 +180,17 @@ target_tools="target-rda" > > > > ## We assign ${configdirs} this way to remove all embedded newlines. This > > > > ## is important because configure will choke if they ever get through. > > > > ## ${configdirs} is directories we build using the host tools. > > > > -## ${target_configdirs} is directories we build using the target tools. > > > > +## > > > > +## ${target_configdirs} is directories we build using the target > > > > +## tools, these are only needed when working in the gcc tree. This > > > > +## file is also reused in the binutils-gdb tree, where building any > > > > +## target stuff doesn't make sense. > > > > configdirs=`echo ${host_libs} ${host_tools}` > > > > -target_configdirs=`echo ${target_libraries} ${target_tools}` > > > > +if test -d ${srcdir}/gcc; then > > > > + target_configdirs=`echo ${target_libraries} ${target_tools}` > > > > +else > > > > + target_configdirs="" > > > > +fi > > > > build_configdirs=`echo ${build_libs} ${build_tools}` > > > > > > What I see is that after this, there are still occasions where inside > > > 'case "${target}"', 'target_configdirs' gets amended, so those won't be > > > caught by your approach? > > > > Good point, I'd failed to spot these. > > > > > > > > Instead of erasing 'target_configdirs' as you've posted, and > > > understanding that we can't just instead add all the "offending" ones to > > > 'noconfigdirs' for '! test -d "$srcdir"/gcc/' (because that would also > > > disable them for host usage), > > > > Great idea, this is what I've done in the revised patch below. > > > > > I wonder if it'd make sense to turn all > > > existing 'target_libraries=[...]' and 'target_tools=[...]' assignments > > > and later amendments into '[...]_gcc=[...]' variants, with potentially > > > further variants existing -- but probably not, because won't you always > > > need the target GCC to be able to build target libraries ;-) -- and then, > > > where we finally evalue '$target_libraries' and '$target_tools', only > > > evaluate the '[...]_gcc' variants iff 'test -d "$srcdir"/gcc/'? > > > > I wasn't really sure about this idea. It feels neater to have one > > list of things we want to build, and just make sure that the list is > > correct by the time we get to the end of the configure script. > > > > Also, making that change would be much larger, and more > > disruptive... I'd prefer to keep things smaller if possible. > > > > The V2 patch below: > > > > - Moves the check for gcc/ to much later in the configure script, > > after we've finished building target_configdirs, > > > > - Makes use of skipdirs to avoid building anything from > > target_configdirs if we're not also building gcc. > > > > All feedback welcome, > > Looks OK to me, so please go ahead unless somebody quickly > disagrees. Thanks, I have now pushed this patch. Andrew