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 12:43, 4 September 2009 by Cdtdoug.gmail.com (Talk | contribs) (Doug's Discoveries)

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

Doug's Discoveries

  • 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. Be careful which one you're looking at. Which ones get actually used?
  • 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).

Back to the top