Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Need help with ScannerInfoProvider and CDT 6.0
I may be at fault here. There is a bug introduced in CDT 6.0 200909110608 in DiscoveryTab.java. I tried circumventing it by adding a scannerConfigDiscoveryProfileId to some InputType specifications in our build definition which had no previous specifiers. It may be that the discovery profile specification circumvents the setting of the default include path I expect.
When I made a patch to DiscoveryTab.java, reverted the change above, and was sure to create a new project, the indexer works again and finds the standard C include in the test example.
Would you like me to still open a bug? I was hoping to get someone I could discuss our build definition with as I would like to clean it up somewhat. I am rewriting the project to be cleaner and would like to avoid passing on any bad practices. 

-- Jeff J.

On 07/10/09 06:09 PM, Andrew Gvozdev wrote:

Hi Jeff,
I don't think there was any intended change to the way how scanner
discovery is working. Please, open a bug in bugzilla to figure that out.
It would be helpful to define what "recently" is if you can be more
specific.

Thanks,
Andrew

On Wed, Oct 7, 2009 at 6:00 PM, Jeff Johnston <jjohnstn@xxxxxxxxxx
<mailto:jjohnstn@xxxxxxxxxx>> wrote:

    Our project has had its own ScannerInfoProvider for a long time
    using the old org.eclipse.cdt.core.ScannnerInfoProvider extension.
      We added it to perform a make -W per file to gather the include
    files and macros.

    This got us all the include paths specified in the Makefile itself,
    but not the default includes.  At the end of the include fetching,
    we would use:

    IScannerInfo info =
    (IScannerInfo)ManagedBuildManager.getBuildInfo(project);
    String[] baseIncludes = info.getIncludePaths();

    This used to get the default include path (e.g. /usr/include) until
    recently.  Now, the info.getIncludePaths(project) returns an empty
    array.

    In debugging, I noticed that the CDT is calling our
    ScannerInfoProvider with one of two imaginary files: __cdt__.cpp and
    __cdt__.c.

    Has the ScannerInfoProvider interface been changed such that the
    default includes are to be generated by "our" ScannerInfoProvider
    when either of these two files are presented or should the
    ManagedBuildInfo still provide this?

    -- Jeff J.
    _______________________________________________
    cdt-dev mailing list
    cdt-dev@xxxxxxxxxxx <mailto: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

Back to the top