[cdt-dev] CDT's handling of compilation switches
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
Names the output file
Names the output file. The default is a.out.
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
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,
IBM Linux Technology Center, Linux Toolchain