RE: [cdt-dev] Include path discovery hardcoded to use "gcc"

["Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>]

Hi John,

The scanner info provider command is not hard-coded actually.
You are able to define the custom Scanner Discovery Profile using any
tool(command) and associate it with your tool-chain definition via a
toolChain::scannerConfigDiscoveryProfileId attribute.
But I agree we should allow modifying the default profile settings for
the tool-chain.
I agree with your approach of having one and the same core and UI
representation of this functionality for the Managed and Standard make
and I think we should be able to do that having the tool-chain concept
introduced to the Standard Make as well that is planned as part of the
New Project Model in 4.0.

>Is there a reason why the tool used for scanning was kept distinct from
the tool used for compiling within CDT?
First of all there is a historical reason for this: the scanner info
provider mechanism is not part of the MBS functionality and knows
nothing about MBS tools. The other thing is that the scanner info
provider command can (theoretically) differ from the tool command used
for compilation, so we should not link them tightly with each other.

IMHO the easiest way to be used for now for solving this issue is to
allow using the Build Macros (Variables) in the profile definition.
This should allow the profile settings to be always consistent with the
tool settings, e.g. we could introduce the "ToolCommand" macro and then
use this macro in the scanner info provider command. This will guarantee
that the provider command will by default always be the same as the tool
command as well as will allow users to modify this behavior by
customizing the info provider command.
This approach can be already implemented with MBS, but once we have the
Build Macros (Variables) concept become part of the core, this approach
can be spread for both Standard and Managed make.

Mikhail

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Dallaway
Sent: Monday, June 26, 2006 2:54 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Include path discovery hardcoded to use "gcc"

I'm looking at options for a fix for bug 117294:

  http://bugs.eclipse.org/bugs/show_bug.cgi?id=117294

Ideally, I would like to fix this by forcing the scanner to use the
user-specified compiler tool for the current managed build project (eg
"arm-elf-gcc") rather than using "gcc".

I have verified that I can hard code a new tool for scanning by
overriding the value of the fCompileCommand variable within
GCCSpecsRunSIProvider.initialize(), but there does not appear to be an
elegant way to access ManagedBuildInfo.getToolForSource() from here
without breaking the existing abstractions.

An alternative approach might be to generalize the "Discovery Options"
code and UI currently used by unmanaged make projects and use them also
for managed make projects. But the user would then have to specify the
compiler tool both in the build tools UI and in the discovery options
UI.

Is there a reason why the tool used for scanning was kept distinct from
the tool used for compiling within CDT?

Any other thoughts on the best way to address this bug would be most
welcome.

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