Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] externalSettingsProvider and built-in settings

Hello Glen,


Thank you very much for sharing your experience with scanner discovery / built-in paths.


I share your views about the approaches to scanner discovery. Some more comments on them according to my experience.


1.)    The simplest case is taken care of by the buildDefinitions/listOptionValue that Andrew mentions below where a tool has a single static set of settings that can be defined once in plugin.xml. This seems to work great and I assume that it satisfies users that fall into this category.


Yes. Unfortunately build macros in listOptionValues are not expanded, otherwise include paths contribution would have been really easy.


2.)    The most complex case is something like a per-file scanner discovery profile which, as you’ve noted, seems to be heavily biased towards GNU tools. Integrating non-GNU compatible tools requires a significant amount of code and (in my experience at least) has proven to be extremely brittle. Small changes in seemingly unrelated code almost always seem to cause something subtle to break. The complexity of the current discovery framework also makes unit testing quite hard so some of these subtle breakages often go unnoticed until they get into a users hands.

3.)    The middle ground is where I’m guessing quite a few folks like you and I live. We have a particular set of tools for which we’d like to dynamically add built-in settings at runtime. We know how to get these settings from our tools, we simply need a straight forward way to tell the build system about them. This use case is where I think we’re falling a bit short.  I really don’t need anything remotely approaching the complexity of scanner discovery but at the same time the simpler methods don’t quite let me do what I need to do.


I agree. A way to contribute include paths and symbols is to reuse the PerProjectSICollector class together with an scannerInfoProvider, which in turn invokes an IExternalScannerInfoProvider2 instance which actually provides the paths and symbols. This has proven to be very fragile and break due to small changes (e.g. source folders “forgetting” include paths at project load time).


Some thoughts I’ve had regarding ways we might fix this:


1.)    I’ve heard that “fixing” scanner discovery is one of the agenda items for Helios. I’m not entirely sure what this means at this early stage but maybe this would be the time to try and address some of these deficiencies?


I hope so too, since I feel this is one of the most obscure tasks in integrating a non-gcc compiler in Eclipse.


2.)    Is there a reason why externalSettingsProvider doesn’t allow a built-in flag? Is this something that we could simply address?  I’d be more than happy to take a swing at providing a patch if I had a sense that there wasn’t some bigger picture reason why it shouldn’t be done.


Other than via externalSettingsProvider s , also programmatically creating e.g.  CIncludePathEntry instances with the BUILTIN flag set in an ICLanguageSettingEntry does not work.


3.)    What about adding a way to programmatically add listOptionValues to an IOption?  We already have IOption.getBasicStringListValueElements() that allows me to retrieve the list. Could we perhaps add a method like IOption.addBasicStringListValueElement(OptionStringValue value) that lets a user programmatically modify the list? Again I’d be happy to open a bug and supply a patch if there was some consensus that it’s a reasonable thing to do.


Having a method to add elements would be great. I tried to hack addition of built-ins by relying on the fact that Option.getExactBuiltinsList() returns the original list of builtins, which can be manipulated. This contributes the paths but does not refresh the project in the UI. An addBasicStringListValue() in IOption which refreshes the project appropriately would solve the situation.






Anyway, so my for my pontificating :) Just thought I’d let you know that we both seem to have had much the same experiences with this particular topic.





From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: Thursday, August 27, 2009 9:15 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] externalSettingsProvider and built-in settings


An update to this: I also tried to use my project listener to programmatically add a CIncludePathEntry with the ICSettingEntry.BUILTIN flag, following the guidelines found at the unofficial CDT FAQ


I am able to add the path, but its BUILTIN flag is ignored.


This discussion


seems to hint that there is no way to modify the builtin settings programmatically! This would also explain why the flags set by the externalSettingsProvider are ignored when the values are actually stored in the project.


So, is the scanner discovery the only viable option to dynamically modify include paths/etc?


Thanks again,





From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: den 26 augusti 2009 16:08
To: CDT General developers list.
Subject: RE: [cdt-dev] externalSettingsProvider and built-in settings


Hi Andrew,


Thanks for your suggestion.


Unfortunately the information provided by the externalSettingsProvider is always dynamic so it can’t be stored in the project or in the toolchain…


I also tried to hack scannerDiscoveryProfile for the same purpose – which seems to be tailored for gcc-like compilers. That almost works but I am getting weird behavior in projects using source folders, so I’d rather go for the externalSettingsProvider way which seems more robust and concise.


The only thing I am missing is the built-in flags to be stored…




From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: den 26 augusti 2009 15:16
To: CDT General developers list.
Subject: Re: [cdt-dev] externalSettingsProvider and built-in settings


Hi Mario,

As an alternative, you could use org.eclipse.cdt.managedbuilder.core.buildDefinitions extension point which lets you define the paths and set builtin flag in listOptionValue.




On Wed, Aug 26, 2009 at 9:00 AM, Mario Pierro <Mario.Pierro@xxxxxxx> wrote:


I am trying to use the externalSettingsProvider extension point to add
include/library paths and predefined symbols programmatically to my
custom project type.

Following the instructions at


I managed to successfully add an external settings provider which is
added to my projects via an ICProjectListener class.

However, flags in the ICSettingEntry instances contributed by the
external settings provider seem to be ignored.

For instance, I am doing the following

   public CExternalSetting[] getSettings(IProject project,
           ICConfigurationDescription cfg) {

       // We provide the same settings for all configurations

       // Create include path entries for all the contributed paths
       List<ICSettingEntry> includeSettings = new
       List<String> includePaths =
       for (String path : includePaths)
           includeSettings.add(new CIncludePathEntry(path,

where the getIncludePaths() will return my custom includes. I also
create CLibraryPathEntry and CMacroEntry objects in a very similar way.

I then create the CExternalSetting containers and send them out to CDT.


       return new CExternalSetting[] {
               // Include paths, for C/C++/ASM
               new CExternalSetting(new String[] {
                       "org.eclipse.cdt.core.g++" },
                       new String[] { "org.eclipse.cdt.core.asmSource"
                       null, includeSettings.toArray(new
               // Library
               new CExternalSetting(
                       new String[] {
"org.eclipse.cdt.managedbuilder.core.compiledObjectFile" },
                       null, librarySettings.toArray(new
               // Symbols
               new CExternalSetting(new String[] {
                       "org.eclipse.cdt.core.g++" }, null, null,
                       symbolSettings.toArray(new ICSettingEntry[0])),


This succeeds in contributing the paths and symbols to the project, but
they are not shown as built-in e.g. in the Include paths tab. Also, the
compiler will be invoked with -D options which attempt to redefine its
predefined symbols...

Is an external settings provider able to contribute built in
symbols/includes/etc.? I have not been able to find any further
documentation on this, nor any examples.

Thank you very much for your help!


cdt-dev mailing list


Back to the top