Difference between revisions of "CDT/Obsolete/ScannerDiscovery61/TracyThoughts"

Latest revision as of 14:04, 22 January 2020

Part architecture/part thoughts, but focussed on the lower-level specifics of the ScannerConfigurationDiscoveryProfile extension

• The extension for a scanner configuration is org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile
• This consists of scannerInfoCollector which is the main class doing the work of gathering the built-ins
  • this is a generic interface although to date the only implementations in the codebase are GCC ones
  • in theory this interface is generic enough to have a non-GNU implemenation of it
  • The scannerInfoCollector implements a whole host of interfaces. Would be nice to clean these up and make it clear which are in use and where they are likely to be called from.
  • The interface IScannerInfoCollectorCleaner contains methods for resetting the discovered methods but following the call hierarchy these methods are never really called from anywhere.
  • the existing implementation of scannerInfoCollector is quite confusing and buggy in places (particularly related to caching builtins)

• The extension point also defines two 'providers' buildOutputProvider and a scannerInfoProvider
  • the latter is very GNU-centric, relying on a specs file and command to run
  • perhaps having some form of more generic infoproviders would be better. We could then provide implementations for spec files, build output, dwarf files and users would be free to extend for their own toolchains
  • each generic infoprovider could reference a scannerparser, defined elsewhere