[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Toolchain updates
|
Thanks James! Works like a champ. That was exactly the nudge I needed!
Glen
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
Sent: Wednesday, May 20, 2009 10:53 AM
To: CDT General developers list.
Subject: 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
CoreModel.getDefault().setProjectDescription(...);
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
other.
Hope this helps,
James
>
> 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
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev