Community
Participate
Working Groups
I have defined a tool chain for Android now (previously I was using the default toolchain). It's now using per file per language discovery which appears to be slightly different, but I haven't figured out how yet. The PerFileSICollector is properly picking up the include paths, but the new scanner info doesn't seem to get registered properly. When I restart the workspace or close and reopen the project, the scanner info does get properly registered as it deserializes the .sc file. So it seems the build path isn't working where the deserialize is. I need to make them behave the same. My current debugging has me at PerFileSICollector.updateScannerConfiguration which does call updateDiscoveredInfo with the right pathInfo. Need to dive into that.
Ah, the updateDiscoveredInfo is what serializes the .sc file. It's fine. I did notice there were no listeners to the change events there. I also noticed that PERFORM_CORE_UPDATE is turned off in the scanner config builder. Digging more...
The core update is another red herring since that seems to be for the .cproject file and scanner info doesn't go there. I need to figure out how the discovered info gets into the system. It isn't happening at build time in my set up. It is during deserialize. Need to go there next.
I'm not in front of a computer... But I seem to remember that scanner discovery hooks off the project description model and loads during the project LOADED event. Check out who extends icprojecrdescriptionlistener, I bet you'll find SD involved somehow.
It doesn't look like anyone implements IDiscoveredInfoListener. Did someone remove them? Or were there never any.
(In reply to comment #3) > I'm not in front of a computer... But I seem to remember that scanner discovery > hooks off the project description model and loads during the project LOADED > event. Check out who extends icprojecrdescriptionlistener, I bet you'll find SD > involved somehow. Nope, I put a breakpoint in the getIncludes method of the CCommandDSC and on project open, it only happens as a side affect of first time someone gets a project description which causes the load of the path info. I just tried adding a path in my makefile. The change didn't get registered then either. There doesn't seem to be any change management in the per file stuff.
Now this is pretty bad. I tried a Makefile project on Linux with the standard per project discovery and tried adding a non-builtin directory outside of the workspace to the include path. It never gets added to the discovery info. I see it in the .sc file but there's a lot of crap in there. I was hoping it was working and would show me how to notify the project model of the path change.
Back to debugging and recording what I'm finding. Just took a look at the indexer side of things, ITranslationUnit.getAST(), and find that, even though I have per file scanner discovery turned on, the DescriptionScannerInfo provider isn't providing per file info.
I think I found it. The call to CfgDiscoverdPathManager.removeDiscoveredInfo() in ScannerConfigBuilder.build() was commented out. However, this is what triggered the new discovery information to get loaded. While it may not make sense to reload it after every build, it does need to be reloaded sometimes. I'll see if I can put the call in the proper strategic place.
*** cdt cvs genie on behalf of dschaefer *** Bug 314015 Test fix for scanner discovery. [*] ScannerConfigBuilder.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/build/core/scannerconfig/ScannerConfigBuilder.java?root=Tools_Project&r1=1.12&r2=1.13
This fix seems to solve it. Marking fixed. Andrew G already has a bug open for the performance issues which we'll have to address for 7.0.1 or 8.
*** Bug 314032 has been marked as a duplicate of this bug. ***
