| RE: [cdt-dev] some questions about CDT c/cpp parsing |
|
No, it’s not complicated. I’m
just wondering out loud how this will all work. Can I always expect there to
always be at least one build configuration? If not, do I need a new piece since
I do getLanguage from a number of different spots and would need to localize
the fallback code. (remember, I hate typing
J). Doug Schaefer, QNX Software Systems Eclipse CDT Project Lead, Tools PMC member From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo >
I’m not sure how things evolve from one to the other to ensure all
languages keep working, though. Maybe the problem is more complicated that I’m thinking, but
I would suggest asking the build configuration for the language, and if it
doesn’t have an answer, fallback to using the content type. Leo From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer Very
true. If I could ask a build configuration for the given ILanguage for a given
ITranslationUnit, then I’m set. Right now, you register the ILanguage
against a content type in the extension point and ITranslationUnit looks things
up there. I’m not sure how things evolve from one to the other to ensure
all languages keep working, though. Something to think about. Doug
Schaefer, QNX Software Systems Eclipse
CDT Project Lead, Tools PMC member From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo Hi Doug, > One problem would be knowing which
parser to use for a given file since we are currently triggering of ContentType
which would need to be different depending on what compiler you were using. This is one of the places where I think the
CDT-wide concept of the current build configuration and associated tool-chain
can help. The C/CPP tool in the tool-chain can specify the language
variant that it understands. Leo |