[cdt-dev] CDT's handling of compilation switches

[Corey Ashford <cjashfor@xxxxxxxxxx>]

A couple of months ago I filed Eclipse Bug #152656 regarding adding 
64-bit compilation for PowerPC, and I got some feedback saying that 
there is a larger issue to be settled in the CDT with respect to 
handling of a huge number of possible architectural switches.

So I got to thinking that one way I've seen this done before is to have 
the underlying tool (gcc in this case) emit a little database that can 
be read by the GUI wrapper (in this case the CDT) to display the 
possible options in a nicely readable and settable format.

So I am thinking to modify gcc have an option, say --emit-options-xml, 
to have it create XML (or other easily machine-readable) output that 
could easily be parsed by the gcc.  The output could be structured so 
that the switches can be in categories, like the existing compiler 
switches in the CDT today.  There's a lot that could be done with this, 
I think. Here's a crude little example of what I'm thinking of:

% gcc --emit-options-xml
<gccoptions>
    <category name="General">
	<option>
		<equivalents>
                   -o
                   --output-file
                </equivalents>
		<arguments>
			<printableascii/>
                </arguments>
                <name>
                Output File
                </name>
                <briefdesc>
                Names the output file
                </briefdesc>
                <detaileddesc>
                Names the output file.  The default is a.out.
                </detaileddesc>
        </option>
        ...
    </category>
    <category name="Architecture">
        ...
    </category>
</gccoptions>


Categories could be nested.  For example, it might be worthwhile to have 
a category called "Advanced".  Within that category would be a 
duplication of some of the outer categories, such as "Architecture" that 
would have the more seldom-used architecture switches.

I realize that this would require coordination between updates to gcc 
and the CDT, but once the CDT part is working, it would make CDT 
automatically adapt itself to any platform's gcc and to any updates to 
gcc's options.

The change to gcc wouldn't be specifically for Eclipse, as any GUI that 
invokes gcc could make use of it.

Is this a solution that sounds workable?  Do you foresee significant 
resistance from the gcc developers, provided that the initial gcc 
patches are supplied?

Moreover, do you think it's worth the effort involved?

Thanks for your consideration,

- Corey

--
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@xxxxxxxxxx