RE: [cdt-dev] ScannerInfoCollector, MBS inputType and code indexerquesti

["Mario Pierro" <Mario.Pierro@xxxxxxx>]

Thanks for your suggestion.

I have inspected how the path discovery works now, and I am able to
contribute discovered paths by associating a custom per-project scanner
discovery profile to the _toolchain_.

Associating a profile to the input types of the tools only did not have
any effect, as the scanner provider never got invoked.

I have now noticed that the CDT indexer is considering the source files
in the projects using my custom toolchain as "excluded", i.e. not
configured for build, since it lacks scanner discovery info about them
(i.e. the CoreModel.isScannerInformationEmpty() always returns true for
the corresponding resources).

When tracing the code indexer debug output, the project always has "0
sources".

How can I have my scanner associate the contributed info also to the
source files?

Thanks,

/Mario

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alex Chapiro
Sent: den 4 februari 2009 19:17
To: CDT General developers list.
Subject: Re: [cdt-dev] ScannerInfoCollector, MBS inputType and code
indexerquestions

I don't remember in details this design, but I believe if in debug 
session you would  set breakpoint in 
DiscoveredPathManager.getDiscoveredInfo, create simple MMB  "Hello" 
project and trace after stop on this breakpoint, you'll get an idea how 
it works.

Regards,

Alex

On 04/02/2009 4:43 AM, Mario Pierro wrote:
> Hello,
>
> I am trying to integrate a custom C/C++, non-gcc-like toolchain using
> CDT MBS.
>
> While the build process is resolving all dependencies between files
> correctly, the CDT code indexer fails to resolve dependencies between
> headers and source files. As an example, it is failing to navigate to
> declarations performed in header files. The toolchain uses a
> IManagedDependencyCalculator implementation to determine dependencies,
> and that works.
>
> I have tried to use the scannerConfigDiscoveryProfileId attribute in
the
> inputType options of the tools to associate a custom scanner in order
to
> resolve dependencies, but this seems to only work when a
> sourceContentType is defined and only with a gcc-like compiler. The
> classes that implement the scanner profile are pointed out in a
> ScannerConfigurationDiscoveryProfile
>
> It is unclear to me what the relation between the following elements
is:
> - a tool's inputType
> - the inputType's scannerConfigDiscoveryProfileId
> - the inputType's sourceContentType / dependencyContentType as opposed
> to sources/dependencyExtension attributes
> - the inputType's languageId
> - the toolchain's IManagedDependencyCalculator
>
> Questions are:
>
> 1) Is the code indexer using the dependency information received from
> the toolchain's IManagedDependencyCalculator? Or does it need a
> dedicated scanner?
>
> 2) Do I need to define a custom sourceContentType for my scanner to be
> invoked? Or can I reuse the CDT-defined types
> (org.eclipse.cdt.core.cSource, etc.)?
>
> 2) Can the scanner discovery work also when the
> sources/dependencyExtension attributes are used to specify the tools
> inputs based on file extension?
>
>
> Thanks in advance for your help!
>
> /Mario
>
>
>
>
>
>
> _______________________________________________
> 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