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

Hello,

I found the cause of my problem, which turned out to have nothing to do
with ScannerInfoCollector directly.

As it took quite some time to figure this out, I post it here as it may
be useful to see if this is a MBS bug or not.

The toolchain definition that I have created has most of the options
declared in the toolchain itself at toolchain level, along with the tool
declarations.

When generating the command line, all the tools are getting the correct
options, implicitly inheriting them from the toolchain when they are not
overridden by the tool.

The problem was that the compilers in the toolchain were not recognized
as parsing C/C++ files at all, since they were not declaring any
includePath option type directly!

In the
org.eclipse.cdt.managedbuilder.internal.core.Tool.supportsLanguageSettin
gs() method, every Tool is asked to provide its options to check whether
it has any language-related option. The problem is on the getOptions()
invocation in:

	public boolean supportsLanguageSettings(){
		IOption options[] = getOptions();
		boolean found = false;
		for(int i = 0; i < options.length; i++){
			IOption option = options[i];
			try {
				int type = option.getValueType();
	
if(ManagedBuildManager.optionTypeToEntryKind(type) != 0){
					found = true;
					break;
				}
.
.
.

The call to getOptions() will correctly inherit options from the tool's
superclasses, but will ignore any options declared in the toolchain as
the inheriting process will go on until a null superclass is found.

The optionTypeToEntryKind() call is used to discover language-specific
options in this case, but it will not get the toolchain options since
they are not inherited, so the tool will not support language settings.

I fixed the problem by explicitly adding an option in the c and c++
compiler tools, which inherited from the toolchain includePaths option.

Is this intended or a bug? Why are the toolchain-declared options
correctly propagated to the command line but ignored in the
supportsLanguageSettings() method?

I had this problem both using the HEAD revision of CDT sources and with
version v200809120802.

Thanks,

Mario


 -----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alex Chapiro
Sent: den 11 februari 2009 17:54
To: CDT General developers list.
Subject: 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)...
>
> /Mario
> ________________________________________
> 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
> indexerquestions
>
>
> 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
> 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
>
>
>
> _______________________________________________
> 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





Back to the top