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

                Hi Mario,

 

                Unfortunately I don’t have a direct answer to your question but I can at least say that I’ve been down this same road and have come to the exact same conclusions with regards to programmatically adding built-in settings to a project.  There are several ways to “almost” get there but each approach seems to fall short in at least one way.  Hopefully if we’re missing something someone else will chime in?

 

                As I’ve been wrestling with this for a few months now myself I’ve had a few observations that I thought I might share.  In general it feels to me as though there are three primary needs for this type of functionality:

 

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.

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.

 

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?

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.

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.

 

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.

 

Glen

 

 

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

 

http://cdt-devel-faq.wikidot.com/

 

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

 

This discussion

 

http://www.nabble.com/Project-model:-More-questions-and-some-feedback-td9840195.html

 

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,

 

/Mario

 

 


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…

 

/Mario

 


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.

Thanks,

Andrew

 

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

Hello,

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

http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg15279.html

and

http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg17432.html

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
ArrayList<ICSettingEntry>();
       List<String> includePaths =
convertToForwardSlashes(getIncludePaths());
       for (String path : includePaths)
           includeSettings.add(new CIncludePathEntry(path,
ICSettingEntry.BUILTIN));
        .
        .
        .

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.gcc",
                       "org.eclipse.cdt.core.g++" },
                       new String[] { "org.eclipse.cdt.core.asmSource"
},
                       null, includeSettings.toArray(new
ICSettingEntry[0])),
               // Library
               new CExternalSetting(
                       null,
                       new String[] {
"org.eclipse.cdt.managedbuilder.core.compiledObjectFile" },
                       null, librarySettings.toArray(new
ICSettingEntry[0])),
               // Symbols
               new CExternalSetting(new String[] {
"org.eclipse.cdt.core.gcc",
                       "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!

/Mario


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

 


Back to the top