Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


Mike Kucera
Rational Multicore Tooling
UI Team Lead
IBM Toronto Lab
mkucera@xxxxxxxxxx


Inactive hide details for "Schaefer, Doug" ---07/18/2011 10:03:03 PM---Hey gang, I'm not sure how many people have done this, b"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

GIF image

GIF image

GIF image


Back to the top