[Bug driver/49858] lost ability to use driver for external language support?

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-07-26 23:31:27 UTC ---
On Tue, 26 Jul 2011, bigotp at acm dot org wrote:

> Is there a mechanism by which the driver can be informed of options that it
> should allow in this situation, given that the list of these options is not
> known at the time the driver is compiled?

No.  By design there is now a structured notion of options shared by the 
driver and cc1 and a single mechanism for option parsing, that 
consistently rejects unknown options rather than having them sometimes 
only inconsistently rejected depending on which phases of compilation are 
run, and that is intended in future to support multilib selection based on 
logical option state rather than option text, and maybe eventually 
disallowing options without --help text.

It was a mistake that specs were ever documented in the user manual; they 
should be considered a purely internal interface between different parts 
of GCC.  It is not expected that you can drop in support for new languages 
without at least part of that support being present when GCC is built 
(GNU/Linux distributors may include the minimal set of files defining 
specs and options for languages such as D and Pascal when they build their 
main GCC packages, for example, so that the driver then supports those 
languages even though the language compilers themselves are built 
separately).

(I do not rule out that the plugin mechanism could be extended in future 
to allow driver plugins, that might modify the unknown option handling, 
but the change away from allowing arbitrary options that just happen to be 
matched by some spec, to having a structured notion allowing a meaningful 
enumeration of all supported options and their associated properties, is 
deliberate.  It would also be reasonable to provide a way to export the 
properties of GCC's options for use in external wrappers to know what 
options take arguments.  But processing options unknown to GCC is outside 
the intended uses of the driver at present, although you may be able to 
find a hack where your wrapper hides them within options known to GCC that 
take an argument but where the driver doesn't validate that argument in 
any way; -fplugin-arg-* might be the most sensible option to use.)