View Issue Details [ Jump to Notes ] [ Print ]
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 [^]
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0014507)
Alex Neundorf (developer)
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

 Issue History
Date Modified Username Field Change
2008-11-15 12:04 Philip Lowman New Issue
2008-11-23 20:45 Miguel Figueroa Status new => assigned
2008-11-23 20:45 Miguel Figueroa Assigned To => Miguel Figueroa
2009-01-09 18:59 Alex Neundorf Note Added: 0014507
2009-01-09 18:59 Alex Neundorf Assigned To Miguel Figueroa => Alex Neundorf
2009-01-09 18:59 Alex Neundorf Status assigned => closed
2009-01-09 18:59 Alex Neundorf Resolution open => fixed

Copyright © 2000 - 2018 MantisBT Team