From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21916 invoked by alias); 23 Oct 2014 15:27:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21905 invoked by uid 89); 23 Oct 2014 15:27:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Oct 2014 15:27:46 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NFRij6021721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 11:27:44 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NFRgho000799; Thu, 23 Oct 2014 11:27:43 -0400 Message-ID: <54491E6E.8080407@redhat.com> Date: Thu, 23 Oct 2014 15:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Ian Taylor , gcc-patches@gcc.gnu.org Subject: Re: Patch RFA: Top-level configure patch: disable go on systems where it doesn't work References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg02416.txt.bz2 On 10/23/2014 04:36 AM, Ian Taylor wrote: > This patch to the top level GCC configure script disables the go > languages on some systems where it is known to not work. Bootstrapped > on x86_64-unknown-gnu-linux. > > OK for mainline? > > Ian > > 2014-10-22 Ian Lance Taylor > > * configure.ac: Disable the Go frontend on systems where it is known > to not work. > * configure: Regenerate. > I think it'd be better if knowledge specific to subdirs was pushed down to the subdirs, rather than being kept in the top level, in the direction of how we disable libatomic, libsanitizer, etc. That is, by sourcing something in the subdir to get back the info top level needs. With that in place, changes to the set of supported hosts/targets/configurations no longer needs to be synchronized between the projects that use the top-level scripts. In the specific case of languages, it seems to be we already have such a script. E.g.: # First scan to see if an enabled language requires some other language. # We assume that a given config-lang.in will list all the language # front ends it requires, even if some are required indirectly. for lang_frag in ${srcdir}/gcc/*/config-lang.in .. ; do case ${lang_frag} in Each config-lang.in sets some output variables. For the case of a language being unsupported for some reason, we'd declare that the lang fragments can specify one more output variable, simply called "unsupported", and then in in go's gcc/go/config-lang.in, we'd add: # Disable the go frontend on systems where it is known to not work. case "${target}" in *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*) unsupported=true ;; esac Then back in the top level, near where we do: # Disable languages that need other directories if these aren't available. for i in $subdir_requires; do test -f "$srcdir/gcc/$i/config-lang.in" && continue ... We'd handle the "unsupported" variable. WDYT? Thanks, Pedro Alves