| [cdt-dev] weird scanner discovery behaviour |
Background: I've been working for several weeks on getting scanner discovery working for the XL C/C++ toolchain, on the cdt_5_0 branch. I've managed to finally make a scanner info collector that simultaneously handles both setting per project data for info discovered from doing the "specs file compile" in verbose mode (for the compiler builtins), as well as per file data discovered from the user's build. After much labour and swearing (it has been far from easy), I now have it so the info is properly discovered and persisted in the project's .sc file that lives in the workspace metadata for org.eclipse.cdt.make.core. So far so good.
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.
Is there a way to refresh the ICLanguageSettingEntry data? 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. The path between where the info gets set in the make.core plugin's IDiscoveredPathManager and how it ends up in the ICLanguageSettingEntry data is not at all clear to me.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto