|Re: [cdt-dev] Scanner Discovery|
Yeah I will say as well that different projects may use different versions of the compiler, installed in different locations, which can cause them to return completely different info. For example with RDT, we might have projects that use the same compiler but the different projects reside on different machines with different compiler levels and install locations. It's good to be able to share the scanner info amongst projects for which the info does not differ, but I'm curious what your definition of "same compiler" is.
Team Lead, IBM CDT and RDT
Andrew Gvozdev ---12/21/2011 10:01:10 AM---Hi Markus, On Wed, Dec 21, 2011 at 3:16 AM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx
Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
12/21/2011 10:01 AM
Re: [cdt-dev] Scanner Discovery
I am thankful that you work on cleaning up this part of CDT and I am sorry that I don’t have the bandwidth to really look into your work. However from your description I do have a question:
Generally speaking, there are command-line options that influence the built-in include-path and macro definitions. Will I lose the ability to customize the compiler inspection on project level?
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Wednesday, December 21, 2011 05:43
To: CDT General developers list.
Subject: [cdt-dev] Scanner Discovery
I've been working on new design for scanner discovery, see http://wiki.eclipse.org/CDT/ScannerDiscovery61 and bug 290631. There are some scenarios how it could be used and screenshots at http://wiki.eclipse.org/CDT/ScannerDiscovery61/Stories.
At that point I've got working version on sd90 branch of CDT repository. The core machinery is done, and UI is usable.
Here are some highlights:
- scanner discovery is naturally associated with build configuration
- inspection of built-in compiler settings is done only once (per compiler), results are available to all projects in workspace
- algorithm of Build Output Parsers is more accurate, takes in consideration build folder, can recognize include and macro files (-include and -macros options), undefine (-U)
- handles EFS
- notification mechanism for changes in the language settings
- Mac Frameworks supported
- extension point for extenders, abstract classes for typical kinds of providers to extend
- means to plug discovery to resource listeners
- switch to back down to the legacy SD just in case
The code in cdt.core was tested, covered with JUnits and pretty well documented, although other parts (build plugins and especially UI) need clean-up/some more work.
The plan is to listen to community feedback and hopefully proceed with incorporating the core part to CDT master. I'd like to include it this early in the release cycle so to have room to fix issues should any arise. The rest is to be cleaned up and gradually added with the objective of Juno release.
So, I count on some feedback. The sd90 branch is being built on Hudson and can be downloaded at https://hudson.eclipse.org/hudson/job/cdt-sd90/. The code is, well, sd90 branch and API is concentrated in org.eclipse.cdt.core/model/org.eclipse.cdt.core.language.settings.providers package.