On Mon, 7 May 2012, Christian Bruel wrote: > Making the driver aware about all possible user defined options seems > unpredictable. Was there any justification on removing this > functionality or did I miss a point with the EXTRA_SPECS ?
There are several motivations behind requiring all options to be defined in .opt files, including: * For multilibs to be selected based on the semantics of options, using values set in gcc_options structures by the same code as in cc1, rather than by textual matching attempting to replicate semantics, the driver needs to understand the semantics of options as similarly as possible to cc1, rather than treating any options purely textually. * Every option supported by the compiler should be listed in --help (and if the missing help information were all filled it, we could then make it a build failure to have an option without help information). * Structured option information enables consistency in how options are processed and errors given for unknown options or arguments. * It would be useful for the compiler to be able to export structured information about all its options for use by tools such as IDEs. There is certainly room for more extensibility in option handling - ideally there would not be one big enum with OPT_* values for all options and one header with all the macros and structures, but instead front-end and back-end options would use some form of separate namespace for their options so the language- and target-independent compiler doesn't see the options for other parts of the compiler; that fits into the modularity theme that ideally it would be possible to build multiple front ends and back ends into the compiler at once, or to build front ends and back ends separately from the compiler. But defining options through use in specs wouldn't be part of that; rather more structured information about each option would need to be provided somehow by a separately built front end or back end. If you want -m options to select arbitrary board support packages (and the existing ability to use -T to name a linker script isn't sufficient), then a -mbsp= option, whose argument is not interpreted by GCC but may be processed by whatever specs you are adding after GCC is installed, would seem better than lots of separate -m options. As for options in specs included with GCC: they are all meant to be in the .opt files. I went through all the specs in all the config/ headers in GCC and added options found to .opt files before disallowing options not included in .opt files, but as there are about 500 such headers it's quite possible I missed some specs-defined options in the process. -- Joseph S. Myers jos...@codesourcery.com
