PATCH RFA: Add Go support to top level configure and Makefiles

[Ralf Wildenhues]

* Ian Lance Taylor wrote on Fri, Nov 19, 2010 at 09:24:13PM CET:
> Does this version (change to configure.ac only) look better to you?

Well, there is one more thing: if target-libffi is already listed, it
will be listed twice now.  You can grep it to avoid duplicate entries.

The patch seems OK to me then, if it works in the following
configurations:
  --enable-languages=c
  --enable-languages=c,go
  --enable-languages=c,go,java

but please leave a bit for other build maintainers to get a chance to
fix my review if need be.  The toplevel changes need to be synced to
src.

> Ralf Wildenhues writes:
> 
> > Aside, I see that libgo/configure handles --disable-libffi.  Since this
> > option is also used at the toplevel to disable the libffi target
> > directories, that seems to imply that, if used, it is always an in-tree
> > libffi that is used.  Is that correct?
> 
> Unless I misunderstand what you are saying, I don't think that is
> correct.  The code in libgo/configure.ac is trying to say that if there
> is an in-tree libffi, it should be used.  If there isn't an in-tree
> libffi, then it will use the system libffi.  If there is neither an
> in-tree libffi nor a system libffi, then libgo will fail to build.

I don't see where libgo/configure.ac errors out when neither in-tree nor
out-of-tree libffi are chosen (rather, the help string says "don't use
libffi").  I'm actually not quite sure whether it is --disable-libffi or
--without-libffi that disables its building (with the directories in
src, --disable is used throughout, but in GCC namings seem to be a bit
inconsistent).  Anyway a patch to merge that would benefit from being
tested in all combinations (in-tree libffi, out-of-tree libffi with
either an in-tree present, or not, and out-of-tree desired but not
present to ensure error).  But that is for another patch to see.

Thanks,
Ralf