Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CDT/Obsolete/ScannerDiscovery61/LeosThoughts
< CDT | Obsolete | ScannerDiscovery61
I was going to write something similar to James, so I'll just add my thoughts to what he wrote.
- The CDT core functionality that is asking for information required to properly parse a source file should be communicating with a new core component with a new name - "scanner discovery" is too confusing. Maybe the "Compilation Environment Manager".
- A Tool-chain provider should be able to define the set of "metadata collectors" that will work for most of its users who are using a particular bulder - so the information is per tool-chain, per builder. For example, a tool-chain may support both the Managed Build builder and the makefile builder. When the tool-chain is used with the MBS, it may be able to provide all of the "source metadata" itself (including user input into its build system specific property pages). However when it is used with the makefile builder, it may be able to provide builtin information itself, but need to provide some other mechanism (e.g. scanner discovery) to find the user defined metadata.
- The user should be able to override the information provided by the tool-chain - add to it, delete from it. The user information needs to be stored as a "delta" that is applied to the information returned by the tool-chain.
- If the user is using an "undefined" tool-chain, should there be a default that only works with GCC - e.g. something similar to the existing scanner discovery? In either case the user should be able to define all of the information herself.
- The "Compilation Environment Manager" will need to implement an "event" mechanism where code can subscribe to be notified when the metadata changes. It should also be possible to distinguish the case where the metadat changes simply because the active configuration has changed - i.e. will some listeners only want to deal with a single configuration's metadata - perhaps for performance reasons?
There should also be a place for CDT core to ask for the "build environment". This would be used by any part of CDT that is going to launch a build tool - e.g. scanner discovery. If the "Compilation Environment Manager" is already the collection point for the include and library paths, then maybe we can have it manage the build executable path as well.