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 <i...@google.com> > > * 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