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

[Doug Schaefer <DSchaefer@xxxxxxx>]

If you can get this change into gcc, we'll add in the integration to the
CDT. The CDT will always need to support old versions of gcc, not to mention
all other compilers that are available. But you got to start somewhere.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com
 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Corey Ashford
> Sent: Monday, October 02, 2006 9:18 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [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
> <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
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev