MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007585CMakeCMakepublic2008-08-29 20:222009-03-13 17:06
ReporterPhilip Lowman 
Assigned ToAlex Neundorf 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007585: Eclipse generator does not add C/C++ system header pathpath to
DescriptionWhen encountering a "#include <vector>" or "#include <set>" or some other STL construct with an Eclipse generated CMake project the IDE displays an icon next to the #include indicating it doesn't know where the header file is. This is presumably because the C/C++


Tested under Eclipse CDT Ganymede


Trivial reproducer:

foo.cc:
====
#include <iostream>
int main()
{
   std::cout << "Hello!" << std::endl;
   return 0;
}

CMakeLists.txt:
====
PROJECT(bar)
ADD_EXECUTABLE(foo foo.cc)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0009122closed Alex Neundorf Eclipse CDT4 generator fails to determine include path when locale not in English 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-08-29 20:22Philip LowmanNew Issue
2008-08-30 23:20Philip LowmanNote Added: 0013246
2008-09-02 17:39Bill HoffmanStatusnew => assigned
2008-09-02 17:39Bill HoffmanAssigned To => Alex Neundorf
2008-09-03 18:16Alex NeundorfNote Added: 0013287
2008-09-03 18:16Alex NeundorfAssigned ToAlex Neundorf => Miguel Figueroa
2008-09-05 08:45Philip LowmanNote Added: 0013302
2008-09-05 12:15Philip LowmanNote Added: 0013306
2008-10-26 23:14Miguel FigueroaNote Added: 0013936
2008-11-18 01:39Philip LowmanNote Added: 0014129
2009-01-09 20:31Alex NeundorfNote Added: 0014510
2009-02-09 23:28Philip LowmanNote Added: 0014877
2009-03-13 17:06Alex NeundorfNote Added: 0015683
2009-03-13 17:06Alex NeundorfAssigned ToMiguel Figueroa => Alex Neundorf
2009-03-13 17:06Alex NeundorfStatusassigned => closed
2009-03-13 17:06Alex NeundorfResolutionopen => fixed
2009-06-08 22:14Philip LowmanRelationship addedrelated to 0009122

Notes
(0013246)
Philip Lowman   
2008-08-30 23:20   
This is presumably because the C/C++ include paths aren't being added to the build. Adding them in the C/C++ Include Paths and Symbols (either manually or via the "Add Contributed" button) seems to temporarily resolve the problem and allow autocompletion on C/C++ functions/classes from the standard libraries. That is, until CMake reruns and nukes the settings.

I suspect if the CMake generator added the proper system includes to the include path all would be well. Not sure how to get these in a portable manor.
(0013287)
Alex Neundorf   
2008-09-03 18:16   
I've seen this issue before, but I'm not sure what to do.
You could do something like:

find_path(STL_INCLUDE_PATH set)
find_path(STDIO_INCLUDE_PATH stdio.h)
include_directories(${STL_INCLUDE_PATH} ${STDIO_INCLUDE_PATH})

This should fix it for Eclipse and should even be portable.
Or should something like this be done automatically by the Eclipse project generator ?
Not sure.
Miguel, what do you think ?

Alex
(0013302)
Philip Lowman   
2008-09-05 08:45   
That's a good idea for a workaround. I'll try it today.

I think it would still be nice for the Eclipse generator to do this automatically.

Also, when generating a new project within Eclipse the following paths get added. I'm not sure how Eclipse knows that GCC is adding these to the default list of include directories, perhaps there is a flag?

/usr/include
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/include/c++/4.2/i486-linux-gnu
/usr/local/include
(0013306)
Philip Lowman   
2008-09-05 12:15   
find_path(STL_INCLUDE_PATH set) will not work because find_path only search standard system paths, apparantly not standard C++ system paths.

Ok, the way to do this (with GCC) is like so (depending on if you want C or C++)

echo | gcc -v -x c -E -
echo | gcc -v -x c++ -E -

Here are the results for my system:
#include <...> search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.3/include
 /usr/include
End of search list.

Is the Eclipse generator used with compilers other than GCC?

The fix for this probably belongs in the CMake Platform modules. CMake could execute the compiler and parse this list and stuff it in a variable that later the Eclipse generator uses to add the system includes.
(0013936)
Miguel Figueroa   
2008-10-26 23:14   
Alex,

I think this should maybe be resolved in some module. If some variable (STL_INCLUDE_PATH/STDIO_INCLUDE_PATH) is set with the include directories I could easily load it for the project files in the eclipse generator. I don't think that these paths should be added in general for the Makefile generator since they aren't really needed (so, they shouldn't be added with the include_directories command).

The other option is calling find_path(STL_INCLUDE_PATH set) from within the generator... can this be done? Does the API support this?

--Miguel
(0014129)
Philip Lowman   
2008-11-18 01:39   
I'm more and more convinced we simply need to find a way to have these paths and preprocessor definitions (which Eclipse does a good job of detecting itself by running GCC) applied somehow internally to Eclipse. See http://public.kitware.com/Bug/view.php?id=8105 [^] which is related to this problem.
(0014510)
Alex Neundorf   
2009-01-09 20:31   
We could add such a check e.g. at the end of Modules/CMakeSystemSpecificInformation.cmake and put some cmake code inside a
if("${CMAKE_EXTRA_GENERATOR}" MATCHES "Eclipse")
endif("${CMAKE_EXTRA_GENERATOR}" MATCHES "Eclipse")

Alex
(0014877)
Philip Lowman   
2009-02-09 23:28   
A user brought this up on the mailing list today.

I think parsing the output of GCC and throwing the system paths in a couple of CMake variables and then reading these in the Eclipse CDT generator source code and applying them internally within CMake will probably work fine, if that's what's being proposed. It's not an ideal solution but it will solve the problem for GCC users at least (probably 99% of Eclipse users).
(0015683)
Alex Neundorf   
2009-03-13 17:06   
Fix in cvs HEAD (1.23 of cmExtraEclipseCDT4Generator.cxx), might make it into 2.6.4.
Please let me know whether it works for you (it seems I have that parsing disabled, at least Eclipse didn't mark the headers as not found in both cases).

Alex