I think I remember something like this,
but I don’t know anymore whether I had the problem to flush the info into
the .sc files, or whether it was getting the paths and symbols shown in the
project properties.
Anyway, I used the ScannerConfigBuilder to
fix one of these problems:
IProject project = …;
project.build(IncrementalProjectBuilder.FULL_BUILD,
org.eclipse.cdt.build.core.scannerconfig.ScannerConfigBuilder.BUILDER_ID,
null, monitor);
But I didn’t use the
ICProjectDescritpionManager, but IDiscoveredPathManager. So you may have a
completely different situation than I.
Good luck, Jens.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Chris Recoskie
Sent: Mittwoch, 25. November 2009
01:44
To: CDT General developers list.
Subject: Re: [cdt-dev] weird
scanner discovery behaviour
> 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
