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

Reply via email to