Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] ScannerInfoCollector, MBS inputType and code indexerquestions

I'll verify once again the current solution, and if it works OK for me, I'd publish an example (essental fragments of of discovery customization on the CDT Wiki (tonight or tomorrow).

On 11/02/2009 6:56 AM, Mario Pierro wrote:
I was using the sources from the version on CDT currently available on
the update site (v200809120802). Switching the sources to HEAD, the
indexer seems more forgiving with the "excluded" source files and is
able to locate the declarations performed in the headers.

Still though, my project appears not to have any source files according
to the CDT scanner, for the same reason as before
(CoreModel.isScannerInformationEmpty is always true).

Somehow, the tools in my toolchain are not being recognized as building
the files, also because the scanner discovery profile is never invoked
unless it is associated with the toolchain directly (and not just with
the inputTypes of the tools)...

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alex Chapiro
Sent: den 10 februari 2009 23:28
To: CDT General developers list.
Subject: Re: [cdt-dev] ScannerInfoCollector,MBS inputType and code

Are you using the latest code from CVS repository? Few days ago I
submitted patch that fixed (I hope) some issues connected with
customization of scannerDiscovery. There is still one problem exists in
current API. The good news is that there is a simple work around (see
bug report #264010). I hope it should work for you as well.

On 10/02/2009 5:04 PM, Mario Pierro wrote:
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

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



-----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

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.



On 04/02/2009 4:43 AM, Mario Pierro wrote:


I am trying to integrate a custom C/C++, non-gcc-like toolchain using

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


inputType options of the tools to associate a custom scanner in order


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

It is unclear to me what the relation between the following elements


- 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!


cdt-dev mailing list

cdt-dev mailing list

cdt-dev mailing list

cdt-dev mailing list

Back to the top