From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mike Kucera
Sent: Tuesday, July 19, 2011 10:26 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType
For XLUPC projects the new project wizard explicitly sets up the language mappings with the LanguageManager.
It has to do this because while source files can be recognized only by content type (.upc) header files cannot (they still use .h). Headers must be mapped to the UPC language or else they will be sometimes be parsed as standard C.
Take a look at XLUpcSettingsWizardRunnable in the org.eclipse.cdt.managedbuilder.xlupc.ui plugin.
"Schaefer,
Doug" ---07/18/2011 10:03:03 PM---Hey gang, I'm not sure how many people have done this, but I'm hoping someone out there can help. I'
From: "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Date: 07/18/2011 10:03 PM
Subject: [cdt-dev] Language extension driven by compiler inputType
Sent by: cdt-dev-bounces@xxxxxxxxxxx
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