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/LeosAddlThoughts
I have some additional thoughts on scanner discovery "contibutors" after the 10/6/2009 CDT Monthly meeting:
- Like CDT error parsers, there will be a number of scanner info contributors but not all of them will be applicable to every configuration
- The Tool-chain for a configuration (more about tool-chains below...) is in the best position to define the default set of contributors for the configuration
- Should scanner discovery info be saved? It may be that each particular contributor should specify whether its own contributions should be saved. That is, each contributor knows whether it is easy to re-generate the information (for example a contributor specifically written to return the built-in macros and include paths for a particular tool-chain) or whether re-generating the information may take significant time (for example, the contributor needs build output in order to "discover" the information). The problem with the contributors that need build output is that the information needed by the parser is not available until the project is built. In fact, there is no way to get the information until the project is in a state where it can compile and/or build successfully.
- Where should scanner discover info be saved? Two alternatives (there may be others) are to save the information in the project file (or some other file that is expected to be under source code control and shared with other project developers) and per-user metadata/settings. The problem with per-user metadata/settings is with contributors that can take a long time. There will be no information for the scanner to use when a new user initially checks out the project.
- If scanner discovery info is saved in the project file, why is the project file constantly changing and is this acceptable? I don't know why, but I don't think it is acceptable. I can guess 2 reasons why
- The code that updates the project's scanner info needs to be smarter in order to recognize when the information actually changes
- The scanner info is being provided as absolute paths and these paths can be different among developers. - I don't think implementing the gcc-style build output parsing as an Eclipse builder that gets assigned to every CDT project is a good idea. I guess the real point is that this contributor should be able to be controlled like all other contributors. For example, a configuration that uses the Managed Build System doesn't need this contributor.
I'd also like to discuss the ToolChain as a CDT core concept. In very early CDTs, I don't think there was any concept of a ToolChain or Configuration anywhere in CDT. There were a few extension points for providing things like error parsers and scanner discovery info. These defaulted to implementations that supported gcc and the user would have to change them otherwise? Next, IBM (Doug and others) introduced the concept of "managed build". This included the concept of configurations and toolchains but only when a project was using the Managed Build System. This situation continued for several releases. For CDT 4.0, Intel (I and others) proposed that configurations and toolchains become core concepts - i.e. that these objects contained information that could be valuable to other parts of the CDT core and other builders besides the Managed Build System. Concurrently with this, the folks that brought us the initial scanner discovery mechanism proposed and implemented all of the PathEntry mechanism. Intel developers (but not me because I was pulled off to do other things) implemented this change in the core project model. One of the main ideas was that someone who wanted to integrate a toolchain into CDT could implement a small subset of the builddefinitions schema and provide some basic information about using a toolchain so that every user did not have to provide this information manually. The small subset includes the ProjectType, Configuration and ToolChain objects in the builddefinitions schema but not all of the information that can be provided about tools and their options that is only currently used by the Managed Build System. These 3 objects (ProjectType, Configuration and ToolChain) can define:
- Information used to populate the CDT New Project dialog box regarding the types of applications that can be built using the toolchain, default configurations, etc.
- The default set of error parsers to use with the toolchain
- A configurationEnvironmentSupplier than can set up the executable, include and library paths for the toolchain to be used when building
- An optionPathConverter that can be used when a toolchain uses a different path syntax than the OS it runs on - is this only used by Cygwin?
- A scannerConfigDiscoveryProfileId that specifes the scanner discovery support to be used with this toolchain
In the new scanner discovery proposal, the scannerConfigDiscoveryProfileId could be replaced by an attribute that specifes the default set of scanner discover contributors to use with the configuration.
The other aspect that I would like to see designed into the new scanner discovery support is support for defining an SDK/Library in a similar manner to how ToolChains are defined in the builddefinitions extension point. The basic idea is that I (as a user) would like to use an SDK/Library with my project. I would like a UI where I could see the available SDKs/Libraries and simply select them to be added to my project. All of the scanner discovery inof and build settings to support the use of the SDK/Library would be added to my project automatically. This would include include paths, library paths, and possibly macro defintions. The implementation would be similar to what I described above for ToolChain. That is, someone who wanted to integrate an SDk/Library into CDT would need to implement a small set of objects/attributes in a CDT schema. Maybe this could just be an extension to the builddefinitions schema.