Notes
(0013246) Philip Lowman (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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 (developer) 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

Issue History
Date Modified	Username	Field	Change
2008-08-29 20:22	Philip Lowman	New Issue
2008-08-30 23:20	Philip Lowman	Note Added: 0013246
2008-09-02 17:39	Bill Hoffman	Status	new => assigned
2008-09-02 17:39	Bill Hoffman	Assigned To	=> Alex Neundorf
2008-09-03 18:16	Alex Neundorf	Note Added: 0013287
2008-09-03 18:16	Alex Neundorf	Assigned To	Alex Neundorf => Miguel Figueroa
2008-09-05 08:45	Philip Lowman	Note Added: 0013302
2008-09-05 12:15	Philip Lowman	Note Added: 0013306
2008-10-26 23:14	Miguel Figueroa	Note Added: 0013936
2008-11-18 01:39	Philip Lowman	Note Added: 0014129
2009-01-09 20:31	Alex Neundorf	Note Added: 0014510
2009-02-09 23:28	Philip Lowman	Note Added: 0014877
2009-03-13 17:06	Alex Neundorf	Note Added: 0015683
2009-03-13 17:06	Alex Neundorf	Assigned To	Miguel Figueroa => Alex Neundorf
2009-03-13 17:06	Alex Neundorf	Status	assigned => closed
2009-03-13 17:06	Alex Neundorf	Resolution	open => fixed
2009-06-08 22:14	Philip Lowman	Relationship added	related to 0009122