Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] CDT 3.0 Scanner Info extension questions

In general, the Intel C/C++ compiler is pretty compatible with the gnu compilers.
Gnu compatibility is one of the goals of the Intel compiler team.
For now, here is the list of Intel compiler supported preprocessor related options:

Preprocessor Options

-A- -A<name>[<value(s)>] -C -D<name>[=<value>] -dM

-E -EP -H -I<dir> -idirafter<dir> -imacros<file>

-iprefix<prefix> -isystem<dir> -iwithprefix<dir>

-iwithprefixbefore<dir> -M -MD -MF<file> -MG -MM

-MMD -MP -MQ<target> -MT<target> -no-gcc -nostdinc

-P -ssp -U<name> -X

Are these options sufficient to use the gcc based Scanner Info support? 
I am happy to do so, as I would like to minimize or actually eliminate
cloning, if possible.
Vladimir, we should probably take this discussion offline at this point.
I will send you the complete list of options via email.
Thanks for the help and quick responses,

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vladimir Hirsl
Sent: Friday, June 17, 2005 4:00 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT 3.0 Scanner Info extension questions

First let me tell you that it would be very beneficial for our discussion if I knew more about Intel's compiler (icc?) and how it is different than gcc. Mostly I am interested in differences in compiler options, especially the preprocessor ones. If it proves that icc is very similar to gcc in that respect, than it would probably mean that very little or no code at all should be cloned.

Here are replies in no particular order :--) :
  1. Unless Intel uses some 'make' utility other than GNU make, I don't see a reason for cloning AbstractGCCBOPConsoleParser and AbstractGCCBOPConsoleParserUtility. Their role is to maintain current working directory based on CDT's build directory and output from 'make'.
  2. Unless icc uses some way other that 'specs' files to specify compiler's internal scanner info GCCScannerConfigUtil and ScannerInfoConsoleParserUtility need not be cloned.
    Also I don't see a reason for cloning GCCSpecsRunSIProvider.
  3. Depending on amount of differences between icc and gcc you probably want to clone all specific console parsers and GCCPerFileBOPConsoleParserUtility. There may be a few more classes that need cloning or refactoring.
  4. References from your plugin to make.core collectors are OK. Again it all depends on differences between icc and gcc.
  5. A reference to ".GCCStandardMakePerProjectProfile" should not concern you as long as you always provide specific profile id when invoking ScannerConfigProfileManager methods who take it (profile id) as an argument.

I hope this help.

Bob, you are the first extender of 'discovery' extension points outside of CDT plugins and you are very welcome to specify any requirements that you may have. I will do my best to improve the 'discovery' design to help your needs.

"Monteleone, Robert" <robert.monteleone@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

06/16/2005 01:31 PM

Please respond to
"CDT General developers list."

[cdt-dev] CDT 3.0 Scanner Info extension questions

I am continuing to work on integrating the Intel compiler into the CDT 3.0 standard make Scanner Info support. The recent changes to the UI (see bugzilla #99275), discovered while implementing against the org.eclipse.cdt.make.ui.DiscoveryProfilePage extension point have worked great, thanks.

I am now working towards getting the standard make Scanner Info "core" support to work.
There are some areas where it is not apparent as to what the proper course of action to take is. Let me share what my approach has been so far. What I have done is pretty involved, but I cannot see an easier approach - please enlighten me if one exists...

I created a new plugin:

In this plugin, I have copied and modified the files which implement the gcc Scanner Info support, from org.eclipse.cdt.make.internal.core.* and customized them for the Intel compiler. It is unclear to me as to whether this is the proper set of such files or not. It seems like the files with ICC (changed from GCC) are

probably necessary. (This file needed to be cloned because it has a class that extends
AbstractGCCBOPConsoleParserUtility which I changed to "ICC" - is this intended?)

Here are the extension point references info in my newly created plugin.xml (in, with embedded questions:


?? Note the class reference to the org.eclipse.cdt.make… plugin is that correct or should there be an Intel version to reference? This would require more code cloning...


<scannerInfoProvider providerId="specsFile">
arguments="-E -P -v -dD ${plugin_state_location}/${specs_file}"




?? Note the class reference to the org.eclipse.cdt.make… plugin is that correct or should there be an Intel version to reference?


<scannerInfoProvider providerId="makefileGenerator">
arguments="-f ${project_name}"

?? Note the class reference to the org.eclipse.cdt.make… plugin. Is that correct or should there be an Intel version to reference? Note how this is different from the run command for the above "per project" implementation



Also, in org.eclipse.cdt.make.core.internal.core.scannerconfig2, I see a reference to ".GCCStandardMakePerProjectProfile," which seems to imply that this file may needed cloning. Upon closer inspection, I don't actually think so, but it is unclear to me.

Any insight appreciated...


Bob Monteleone
Intel Corporation
cdt-dev mailing list

Back to the top