From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4190 invoked by alias); 29 Mar 2011 23:29:29 -0000 Received: (qmail 4157 invoked by uid 22791); 29 Mar 2011 23:29:27 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Mar 2011 23:29:22 +0000 Received: (qmail 21954 invoked from network); 29 Mar 2011 23:29:22 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Mar 2011 23:29:22 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1Q4iLg-00028l-Qo; Tue, 29 Mar 2011 23:29:20 +0000 Date: Tue, 29 Mar 2011 23:29:00 -0000 From: "Joseph S. Myers" To: DJ Delorie cc: gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, newlib@sourceware.org Subject: Re: On the toplevel configure and build system In-Reply-To: <201103292228.p2TMSAPB006048@greed.delorie.com> Message-ID: References: <201103292228.p2TMSAPB006048@greed.delorie.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00184.txt.bz2 On Tue, 29 Mar 2011, DJ Delorie wrote: > > 2. If you put directories from the GCC repository into your build, you > > should expect GCC and its libraries to be built; toplevel should not > > disable GCC on the grounds that GCC does not support a given target. > > I disagree. We have a single combined gcc+binutils+etc internal tree > that's used for many targets; some support gcc, some do not. I added > another "don't build gcc for this" just last week. Well, disabling gcc for targets where it is unsupported is hardly consistent existing practice in the FSF tree; before my patch there were just two targets (c54x*-*-* | tic54x-*-*, v810-*-*) disabling the gcc directory, so that patch makes things consistent with the normal practice for non-gcc-supporting targets by removing those special cases. I don't however object much to toplevel disabling gcc on targets without support (if you have a GCC-only tree, it *does* seem unfortunate for configuring it for an unsupported target to quietly build nothing and exit with status 0, instead of exiting with error status), as long as it is done consistently in accordance with principle 4: that is, through config.gcc being adapted so toplevel configure.ac can use it to get positive information from the gcc/ directory about supported targets, rather than through negative declarations at toplevel for unsupported targets. And much the same applies to other components in a unified tree: negative declarations that something is unsupported are much worse than positive information from a subdirectory about what is supported there, and it would be good for one-component-only trees to be able to give meaningful errors if nothing useful gets built - maybe some check is needed to give errors if no installed host tool or target library would be built. -- Joseph S. Myers joseph@codesourcery.com