Re: [cdt-dev] weird scanner discovery behaviour

[Chris Recoskie <recoskie@xxxxxxxxxx>]

> A hacky way would be to get... and set... it. This would force through
> and reconcile all the external changes. You could do this at the end
> of your scanner discovery build while the workspace lock is held.

Did the following:

// reload project description to hopefully get the data to take
ICProjectDescriptionManager descriptionManager = CoreModel.getDefault().getProjectDescriptionManager();
ICProjectDescription cProjectDescription = descriptionManager.getProjectDescription(project, ICProjectDescriptionManager.GET_IF_LOADDED);
// setting the same project description again is supposed to reconcile all the changes
descriptionManager.setProjectDescription(project, cProjectDescription, true /*force it*/, monitor);
// pray...

Didn't work :-(

I tried hacking AbstractCExtensionProxy to try to get it to force an update when the new project description is applied, but that didn't help either.

protected boolean doHandleEvent(CProjectDescriptionEvent event){
boolean force = false;
switch(event.getEventType()){
case CProjectDescriptionEvent.LOADED:
force = true;
case CProjectDescriptionEvent.APPLIED:
force = true; // changed to see if we can force scanner info to update
ICProjectDescription des = event.getNewCProjectDescription();
if(des != null){
updateProject(des.getProject());
return checkUpdateProvider(des, force, true);
}
break;
}

return false;
}

I'll keep digging I guess. Any further thoughts you have would be appreciated.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
James Blackburn <jamesblackburn@xxxxxxxxx>

James Blackburn <jamesblackburn@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

11/24/2009 05:38 PM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] weird scanner discovery behaviour

Hi Chris,

I don't use scanner discovery (other than to provide the built-ins), but...

2009/11/24 Chris Recoskie <recoskie@xxxxxxxxxx>:
> The problem is that any scanner info that is created after the
> ICProjectDescription has been loaded does not properly show up in the Paths
> & Symbols information, nor does it seem to be in the scanner info that is
> passed to the parser. The info on the built-ins, which is created by the
> scanner config builder during the load of the project description, is
> properly there, but the per-file info from the user's build is not there.
>
> If I close and reopen the project, the new info that was serialized
> previously to the .sc file then shows up everywhere it ought to.
>
> So basically, it seems that the ICLanguageSettingEntry data in the project
> description doesn't get updated at all except when the ICProjectDescription
> is being loaded fresh.

A lot of the contributions hang off and contribute via the
ICProjectDescriptionListener interface tweaking the description as its
loaded / changed. Having a quick poke at the code, there's the
DescriptionScannerInfoProvider and created from
ScannerInfoProviderProxy -- both of these inherit from
IScannerInfoProvider.

> Is there a way to refresh the ICLanguageSettingEntry data?

This is one of the big problems with the model. It caches everything
which is bad for memory and consistency. I had a little bit of a
battle to make it adapt to external changes to the environment.

> Failing that, is
> there a way to force the ICProjectDescription to reload? I am at my wits end
> as far as how to get the contributed scanner info to show up otherwise.

A hacky way would be to get... and set... it. This would force through
and reconcile all the external changes. You could do this at the end
of your scanner discovery build while the workspace lock is held.
There is so much broken in Scanner Discovery (and no documentation)
that fixing it is a serious challenge.

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