This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gccgo: A gcc frontend for Go, a new programming language
On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:
> My feeling is that Google's Go (quite a nice language from the slides I just
> have read) is almost "canonically" the case for a front-end plugin.
Well, if you really wish to impede host portability in several different
ways.
* Use of a plugin drops portability to all non-ELF hosts.
> That is, gccgo could be the following shellscript
* Use of a shell script for an installed tool drops portability to MinGW
hosts (see recent discussion of how while using MinGW as a *build* system
is a pain because of all the other infrastructure needed to support shell
scripts and other tools for the build, it works fine as a *host*).
> #! /bin/sh
> gcc -fplugin=gofrontend.so $*
* Use of $* drops support for file names with spaces in (and various other
cases), use "$@".
(Note: I have not looked at whether there are in fact host or target
portability issues with the present implementation.)
I'm sure GNU/Linux distributors would find it useful to be able to build
front ends separately from GCC rather than needing to patch in several
different out-of-tree front ends. But plugins (in the .so sense, as
opposed to dropping in another executable alongside cc1 etc. and providing
the objects needed to build such executables) may not be the best approach
for that (rather, I'd imagine per-language specs potentially being read
from a file by the driver). And users *should* be able to use just the
"gcc" driver for all languages rather than needing separate drivers for
each language, and not need special options for a particular language.
(For some of the less esoteric languages distributors find themselves
patching in, I'd favour integration in the GCC source tree, but the
maintainers of the front ends don't generally seem to have been interested
in that.)
--
Joseph S. Myers
joseph@codesourcery.com