[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT's handling of compilation switches
|
In a former life at another company we used to do something similar. We
did not do the translation at runtime though, we did it at "compile time"
and thus the plugin that held the markup for the MBS options was static.
Since the compiler didn't change too often, this was relatively manageable,
but not without problems. Even within one organization there were still
issues with the compiler team updating the XML in new ways without telling
us. There were also issues in that the compiler used for different
instruction set architectures varied wildly in terms of the base common
compiler code, so some ISAs had really old compilers and hence had really
old and buggy XML that they would output. This ultimately led to a lot of
hackery on my part to workaround the variations... enough that ultimately
it was less work to stop updating the translater and just tweak manually
the plugin.xml it would produce.
I suspect that these problems will be magnified when dealing with an
external community with the size and diversity of the GCC community (there
are umpteen vendors shipping their own GCCs of varying vintages to support
their own ISAs). Not that I want to dissuade you of course, but you should
know what you're getting into.
There are a lot of problems you will have to solve as well that I didn't
have to solve in my little microcosm. E.g., if the build definitions are
truly dynamic at runtime, then you can end up with a lot of versioning
issues, as versions of the compiler that support new or even potentially
entirely different sets of options can crop up. Since your XML translator
is fixed, you have no real way of knowing ahead of time what you might get,
and hence it might be nigh impossible for your translator to know how to
change a project created using GCC version X into something for GCC version
X+1.
Eclipse startup time will also potentially be an issue. Invoking this
scheme on all the GCCs that CDT knows about and parsing their output will
take time. I don't think that's something you want to do on every startup
or even every time you create a project.
Anyway, I'm not trying to be too much of a naysayer. It's a good idea.
Implementation will be far more than trivial however :-)
Thanks,
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Corey Ashford
<cjashfor@xxxxxx.
com> To
Sent by: cdt-dev@xxxxxxxxxxx
cdt-dev-bounces@e cc
clipse.org
Subject
[cdt-dev] CDT's handling of
02/10/2006 09:17 compilation switches
PM
Please respond to
cjashfor@xxxxxx.c
om; Please
respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
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
