MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008105CMakeCMakepublic2008-11-15 12:042009-01-09 18:59
ReporterPhilip Lowman 
Assigned ToAlex Neundorf 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008105: CMake: 2.6.2 Eclipse: CDT (Ganymede SR1) OS: Windows XP Compiler: MinGW Part of the .cproject file that gets generated with the
DescriptionCMake: 2.6.2
Eclipse: CDT (Ganymede SR1)
OS: Windows XP
Compiler: MinGW

Part of the .cproject file that gets generated with the Eclipse generator contains a reference to "gcc" as the command to run (see below). This causes a warning to popup when trying to build the project on MinGW (obviously because gcc isn't called gcc there).

Here is the error message:

Error launching external scanner info generator (gcc -E -P -v -dD P:/code/cdt_workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp)

Here is the affected part of the .cproject file. Modifying command from "gcc" to "C:/MinGW/bin/mingw32-gcc.exe" fixed the warning for me. I assume that the generator simply needs to output a reference to the C compiler instead of hardcoded gcc.

<scannerInfoProvider id="specsFile">
<runAction arguments="-E -P -v -dD ${plugin_state_location}/${specs_file}" command="C:/MinGW/bin/mingw32-gcc.exe" useDefault="true"/>
<parser enabled="true"/>
</scannerInfoProvider>


On a completely separate note, although this scanner problem should be fixed, I can't seem to find a way to tell Eclipse that what it finds via the scanner should be automagically applied to the project (right now it's not) so fixing this problem would at the moment simply correct an annoying warning. The greater problem is that defines like WIN32 detected by this scanner aren't being applied by the Eclipse parser so the net effect is the user needs to define these himself if he wants to be able to effectively use Eclipse.

This can be done manually via "Project Properties->C/C++ Include Paths and Symbols->Add Contributed" but the effect is obviously temporary until CMake reruns. This is somewhat related to Bug 0007585 since this scanner seems to be detecting include paths as well as preprocessor defines.

http://public.kitware.com/Bug/view.php?id=7585 [^]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-11-15 12:04Philip LowmanNew Issue
2008-11-23 20:45Miguel FigueroaStatusnew => assigned
2008-11-23 20:45Miguel FigueroaAssigned To => Miguel Figueroa
2009-01-09 18:59Alex NeundorfNote Added: 0014507
2009-01-09 18:59Alex NeundorfAssigned ToMiguel Figueroa => Alex Neundorf
2009-01-09 18:59Alex NeundorfStatusassigned => closed
2009-01-09 18:59Alex NeundorfResolutionopen => fixed

Notes
(0014507)
Alex Neundorf   
2009-01-09 18:59   
Fixed in cvs HEAD. Hopefully gets into cmake 2.6.3.
But it is still hardcoded for a gcc compiler (i.e. cl + nmake won't work).

Alex