Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDT/Obsolete/ScannerDiscovery61/ExistingArch

< CDT‎ | Obsolete‎ | ScannerDiscovery61
Revision as of 13:27, 5 September 2009 by Angvoz.dev.gmail.com (Talk | contribs) (Andrew's notes to himself)

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.

  • Discovery profile is defined as extension point org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile

Org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile2.png

  • 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
  • There are 2 types of profiles, those with scope per "project" and others per "file".
  • 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.
  • I am thinking about different UI design to present discovery profiles similarly to Binary Parsers or ErrorParsers tab.

Back to the top