[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] CDT's handling of compilation switches
- From: Chris Recoskie <recoskie@xxxxxxxxxx>
- Date: Tue, 3 Oct 2006 06:14:01 -0400
- Delivered-to: firstname.lastname@example.org
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
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 :-)
Team Lead, IBM CDT Team
Sent by: cdt-dev@xxxxxxxxxxx
[cdt-dev] CDT's handling of
02/10/2006 09:17 compilation switches
Please respond to
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
cdt-dev mailing list