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 jos...@codesourcery.com
