[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Language extension driven by compiler inputType

Part of the rationale at the time was that you needed to be able to configure languages for the parser, even if you weren't using the CDT build system. Plus, maybe you'd want to override what the toolchain was specifying anyway.

At the time as well the new-fangled CDT build model was, well, new, and no one understood how it worked, or knew for sure if it was even going to go into CDT yet, so the choice was made to keep it all decoupled.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Inactive hide details for "Schaefer, Doug" ---07/19/2011 10:11:23 AM---Good point re the scanner info. It probably makes the mo"Schaefer, Doug" ---07/19/2011 10:11:23 AM---Good point re the scanner info. It probably makes the most sense to hook up getLanguage to the build


From:

"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>

To:

"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Date:

07/19/2011 10:11 AM

Subject:

Re: [cdt-dev] Language extension driven by compiler inputType

Sent by:

cdt-dev-bounces@xxxxxxxxxxx




Good point re the scanner info. It probably makes the most sense to hook up getLanguage to the build system using a similar method as getScannerInfo.

I’m assuming the ids mean the same in build as in core. That’s what I would have done. I should go back through time and see if the build side was ever hooked up.

Doug.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
Sent:
Tuesday, July 19, 2011 2:51 AM
To:
CDT General developers list.
Subject:
Re: [cdt-dev] Language extension driven by compiler inputType

We have public API to determine the language of a translation-unit, what you get from there can be configured via workspace/project/folder and file settings:
ITranslationUnit.getLanguage().
The API is reasonable, nevertheless, there may be a disconnect with the build-system and there may be a need to change the implementation. I am not sure whether the build-system uses the same language ids and whether they have the same meaning?

The scanner configuration (IExtendedScannerInfo) represents the input to the preprocessor, it should not carry other information, such as the language id.
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent:
Tuesday, July 19, 2011 04:51
To:
CDT General developers list.
Subject:
Re: [cdt-dev] Language extension driven by compiler inputType
Importance:
Low

I don’t think that was the design intent. The idea is that a given file in the active configuration has a language and a lot of work is done in MBS to figure out which inputType to use to figure that out. Stick a breakpoint in InputType.getLanguageId() to see it in action.

Digging into things a little (lot) deeper, I can see where CLanguageSettingCache actually has the languageId with it. The DescriptionScannerInfoProvider has access to it when creating the ExtendedScannerInfo which gets passed up to the parser in TranslationUnit.getAST() but it doesn’t pass it along. Funny enough a couple of lines later it tries to figure out the ILanguage, so close, so far.

Maybe the right answer is to add the language to the ExtendedScannerInfo so that TranslationUnit can get at it. Anyone have an opinion on that?

Doug.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent:
Monday, July 18, 2011 10:38 PM
To:
CDT General developers list.
Subject:
Re: [cdt-dev] Language extension driven by compiler inputType

You can inquire IConfiguration->ITool->IInputType inside MBS but I don't think you can get language to core that way. That would be ambiguous anyway as there could be several tools in toolchain and you can't access the tools from core.
You probably need to introduce a new content type and find the language from file extension via content type. I looked briefly and it seems that CConfigurationDescription.getLanguageSettingForFile() works that way.

Andrew
On Mon, Jul 18, 2011 at 10:02 PM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> wrote:
Hey gang,

I’m not sure how many people have done this, but I’m hoping someone out there can help. I’m writing a build integration for a new compiler (new to CDT at least). It supports a few language extensions. Now I thought I’d try by setting the languageId attribute in the inputType element of my compiler and figured that information should somehow get to the scanner. But no luck.

As far as I can tell, the gcc languages work because their the default, not because of the languageId setting in the build definitions. Has someone got this to work and can point me where I’m missing something.

Thanks,
Doug.

_______________________________________________
cdt-dev mailing list

cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


GIF image

GIF image