CDT/Obsolete/ScannerDiscovery61/ExistingArch

Document the existing architecture from it's main client, the parser, to the individual providers.

Doug's Discoveries

I'm going about this bottom up, from the parser up to the points where the built-ins and the build output parsing is done.

• At the core of the Scanner Discovery profile is the IScannerInfo interface. It has two methods, getIncludePaths, and getDefinedSymbols. It is used by a number of clients to determine the compiler options to help with parsing.
  • Note that for gcc, it's more than just -I and -D, the -m args for example can change the built-in defines. IScannerInfo is supposed to hide all that from the parser. Wonder if it should be hidden?
• There is also an IExtendedScannerInfo that adds is additional methods for other command line options (mainly from gcc) that can affect the compile, e.g. macro files, include files, and local include paths.
• The IScannerInfo type hierarchy is very interesting. e.g. there are two ScannerInfo classes.
• IScannerInfoProvider gets a IScannerInfo for a particular IResource.
• For Makefile project, CCorePlugin.getScannerInfoProvider(project) returns a ScannerInfoProviderProxy. The proxy farms out operations to a DescriptionScannerInfoProvider (why is it a proxy?). In turn, the DescriptionScannerInfoProvider gets the scanner info from the project description (i.e. .cproject file). It returns an ExtendedScannerInfo.
• The ExtendedScannerInfo objects seem to be created when the project description is loaded. Also created when CModel is built and when index is rebuilt. But cached after those operations.
• ExtendedScannerInfo properties set from PathEntry properties in DescriptionScannerInfoProvider createProjectScannerInfo(), createScannerInfo()
• PathEntry objects (ICLanguageSettingPathEntry) are created by ProfileInfoProvider from info found in PathInfo objects
• PathInfo objects managed by CfgDiscoveredPathManager derived from IDiscoveredPathInfo.
• IDiscoveredPathInfo can be per file or per project.
• IDiscoveredPathInfo populated by ScannerInfoCollectors (e.g. DefaultGCCScannerInfoCollector).

Andrew's notes to himself

I've started another bottom-up, from UI DiscoveryTab. I'll try to untangle the code to the point when I can understand what is going on. Those would be my notes about details I found easy to forget. Hope to meet Doug somewhere up.

• Initial roaming
  • Discovery profile is defined as extension point org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile
  • In MBS buildDefinitions extension point the profiles can be connected to toolchain or input type
  • One can see scanner discovery traces setting TraceUtil.SCANNER_CONFIG to true
  • It is easy to see that there are 2 types of profiles, those with scope per "project" and others per "file". Does anybody knows exactly what these are supposed to mean?
  • Per "project" is presented as per "configuration-wide" in UI. This would list all profiles in configuration(?) currently including those "per file" which I believe is incorrect. Gets the list of tools then profiles are taken from InputType. Profiles defined on toolchain level seem to be ignored.
  • Per "file" is presented as "per-language" but broken to per-tool. Profiles pulled from InputType of the tool. The code may refer to it as PerRcTypeDiscovery.
    • Need to look deeper into that. There is some indication that perRCTypeDiscovery is not connected to "per file" profile. Debugging shows "per project" profile being applied for perRCTypeDiscovery in CommonBuilder.createBuildOutputSniffer().
    • isRcTypeBasedDiscovery is an attribute of Toolchain. If isRcTypeBasedDiscovery=false, only one createBuildOutputParser is listening to build output providing default configuration as a context.
    • Project properties DiscoveryTab controls isRcTypeBasedDiscovery via "Discovery profiles scope". Switching scope there changes the way profiles are applied, i.e. sets Toolchain.isRcTypeBasedDiscovery.
  • Class PreferenceInitializer does initialization of Discovery Options defaults for Makefile Project (Preferences->New CDT Project Wizard->Makefile Project)
  • Class SCProfileInstance instantiates classes defined in extension point ScannerConfigurationDiscoveryProfile
  • GCCSpecsRunSIProvider to get compiler specs is being called for every tool. However in long chain of calls that distinction is lost (in IDiscoveredPathManager.IDiscoveredPathInfo.loadPathInfo()). Only configuration is available there. (not 100% sure)
    • In CommonBuilder.contributeToConsoleParserList() InfoContext instance is formed where its ID contains semicolon separated list of IDs: "cfg.id;resource.id;tool.id;input.type.id"
  • CfgScannerConfigUtil.getDefaultProfileId() assigns "selected" profileId. Some logic there.

• Where it is hooked up
  • The first time scanner discovery is run is on creating project description deep inside CProjectDescriptionManager.setProjectDescription(). CfgDiscoveredPathManager.loadPathInfo() calls ScannerConfigBuilder.build(). There seems to be intention to cache but setCachedPathInfo() calls are commented out.
  • One place where IExternalScannerInfoProvider providers are invoked is CfgSCJobsUtil.getProviderScannerInfo(). The providers are taken from IScannerConfigBuilderInfo2 buildInfo.getProviderIdList().
  • CommonBuilder.createBuildOutputSniffer() iterates over all input types for all tools and calls contributeToConsoleParserList() where IScannerInfoConsoleParser is created from profile and added to the list.

• I am thinking about different UI design to present discovery profiles similarly to Binary Parsers or ErrorParsers tab.