Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Scanner Discovery
Hi Chris,
That is something that is up to a provider (language settings provider). In default implementation the compiler is taken from the toolchain and the provider will supply options such as gcc option "-v" (to print built-in specs). The supplied options are configurable, you can arrange to run command remotely on your target box. If you set up different configurations for different machines/locations it will be run on each one and dispatched to proper configuration. We have remote development in-house and I set up a provider running discovery on the remote box for AIX compiler remotely via ssh for myself.

Thanks,
Andrew

On Wed, Dec 21, 2011 at 10:15 AM, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:

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.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Inactive hide details for Andrew Gvozdev ---12/21/2011 10:01:10 AM---Hi Markus, On Wed, Dec 21, 2011 at 3:16 AM, Schorn, MarkusAndrew Gvozdev ---12/21/2011 10:01:10 AM---Hi Markus, On Wed, Dec 21, 2011 at 3:16 AM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx


From:
Andrew Gvozdev <angvoz.dev@xxxxxxxxx>

To:
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Date:
12/21/2011 10:01 AM

Subject:
Re: [cdt-dev] Scanner Discovery

Sent by:
cdt-dev-bounces@xxxxxxxxxxx



Hi Markus,

On Wed, Dec 21, 2011 at 3:16 AM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx> wrote:
    Hi Andrew,

    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:


Thanks. I am still counting on your advice when I need help on indexer issues.
 
    The scanner discovery can be different for each project. For instance I have a project where I use the new c++ standard and another where I don’t. In the former case I pass the extra argument ‘-std=c1x’ to the compiler inspection in the latter I don’t.

    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?


The framework is designed to provide an ability like that for individual language settings providers. Actually, until recently I had a toggle in UI to do that per provider but I had hard time to explain the purpose to others and removed it from options page. Your case gives a strong justification to reinstate the option.

Thanks,
Andrew
 
     

    Markus.

     

     

    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

     

    Hi,

    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.

     

    Thanks,

    Andrew

    _______________________________________________
    cdt-dev mailing list
    cdt-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


GIF image

GIF image

Back to the top