Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Toolchain updates

Hi Glen,

2009/5/20 Anderson, Glen <Glen.Anderson@xxxxxxxxxx>:
>        ArrayList<String> providerIds = ... // the list containing my id
>        // get the IConfigurationDescription for this IConfiguration. This
>        // returns a CConfigurationDescriptionCache object
>        ICConfigurationDescription configDescription =
>                ManagedBuildManager.getDescriptionForConfiguration(config);
>        // this throws a WriteAccessException exception
>        configDescription.setExternalSettingsProviderIds(providerIds.toArray(new String[0]));
>        The call to setExternalSettingsProviderIds() seems to always fail because the CConfigurationDescriptionCache is read-only. The only
> time it seems writable is in very small window during creation.  I wonder if I need to somehow get my hands on an actual
> CConfigurationDescription rather than a *Cache object? If so how? My head is still spinning a bit trying to understand the relationship of the
> various description objects in the MBS.

The default ICfgDescs are indeed read-only.

If you take a quick look at
ManagedBuildManager#getDescriptionForConfiguration(...) you'll see how
it gets the configuration description for a given build configuration.

So in your case you could do something like:

IConfiguration cfg = ...
ICProjectDescription projDes =
CoreModel.getDefault().getProjectDescription(project, true);
des = projDes.getConfigurationById(cfg.getId());

// Set-up the external Settings Provider


ICfg and ICfgDesc are slightly different. ICfgDesc is a cdt.core
concept that's persisted and contains just enough information for the
indexers, parsers, etc to work. The IConfiguration (which is stored in
a given CfgDesc) contains the build system metadata for you project.
So there's a dependency from ICfg to ICfgDesc but not the other way
around. As a user of the API you can obviously go from one to the

Hope this helps,


>        Thanks again for all your help,
>        Glen
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: Tuesday, May 19, 2009 4:49 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Toolchain updates
> Hi Glen,
> 2009/5/19 Anderson, Glen <Glen.Anderson@xxxxxxxxxx>:
>> Presumably it should be done
>> immediately after the project is created or opened so I've implemented
>> an IResourceChangeListener to track the event. The problem that I'm
>> running into though is that even this event is called too early because
>> the ICCConfigurationDescription objects are still not completely done
>> initializing (e.g. doneInitialization() has not been called yet so
>> calling setExternalSettingsProviderIds() throws an exception).
>>        Any advice on the best strategy for initializing the providers?
>> Maybe some example(s) somewhere? Of course it's entirely possible
>> (probable) that I'm just missing something obvious here too :)
> In my case I only hook in the external provider when certain tool
> options are enabled.
> If you want to hook it in immediately after project creation then you
> could register a listener for CProjectDescrtipionEvents with:
> CCorePlugin.getDefault().addCProjectDescriptionListener(ICProjectDescriptionListener,
> CProjectDescriptionEvent.APPLIED)
> These events are fired during project description life cycle including
> project serializing. A fair bit of CDT is drive from these events, so
> they fire multiple times after project creation as scanner discovery
> etc. takes place..
> Cheers,
> James
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top