MantisBT - CMake
View Issue Details
0015597CMakeCMakepublic2015-05-29 14:562016-01-04 11:52
Anthony Ette 
Gregor Jasny 
normalmajoralways
closedfixed 
MicrosoftWindows7
CMake 3.2.2 
CMake 3.4CMake 3.4 
0015597: Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator
The project compiles and links in Eclipse but the preprocessor symbols are not defined by the .cproject file. As a result, sections with

#ifdef _WIN32
#endif

appear grayed out in the IDE and any included files can't be opened. Note that I'm using Eclipse 4 (Luna).

Is there any way I can ensure that the Eclipse project has knowledge of my toolchain's preprocessor symbols without having to redefine them all in my CMakeLists.txt file(s)?
1) setup project with in source build for better eclipse support (see http://www.cmake.org/Wiki/Eclipse_CDT4_Generator [^])

2) run cmake with the following (please see attached toolchain file for reference):

C:\Users\bzpl46\sim\sandbox\AE3007\C2>cmake -DCMAKE_TOOLCHAIN_FILE=toolchains\to
olchain_windows_vsc.cmake -G "Eclipse CDT4 - NMake Makefiles"
-- The C compiler identification is MSVC 15.0.30729.1
-- The CXX compiler identification is MSVC 15.0.30729.1
-- Eclipse version is set to 4.4 (Luna). Adjust CMAKE_ECLIPSE_VERSION if this is
 wrong.
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
9.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
9.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi
o 9.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi
o 9.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- CMAKE_CURRENT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- CMAKE_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- CMAKE_CURRENT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- PROJECT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- PROJECT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- EXECUTABLE_OUTPUT_PATH: C:/Users/bzpl46/sim/sandbox/AE3007/C2
-- LIBRARY_OUTPUT_PATH:
-- CMAKE_MODULE_PATH:
-- CMAKE_COMMAND: I:/PortableApps/cmake-3.2.2-win32-x86/bin/cmake.exe
-- CMAKE_ROOT: I:/PortableApps/cmake-3.2.2-win32-x86/share/cmake-3.2
-- CMAKE_CURRENT_LIST_FILE: C:/Users/bzpl46/sim/sandbox/AE3007/C2/CMakeLists.txt

-- CMAKE_CURRENT_LIST_LINE: 90
-- CMAKE_INCLUDE_PATH:
-- CMAKE_LIBRARY_PATH:
-- CMAKE_SYSTEM: Windows
-- CMAKE_SYSTEM_NAME: Windows
-- CMAKE_SYSTEM_VERSION:
-- CMAKE_SYSTEM_PROCESSOR:
-- UNIX:
-- CMAKE_SKIP_RULE_DEPENDENCY:
-- CMAKE_SKIP_INSTALL_ALL_DEPENDENCY:
-- CMAKE_SKIP_RPATH: NO
-- CMAKE_VERBOSE_MAKEFILE: FALSE
-- CMAKE_SUPPRESS_REGENERATION:
-- CMAKE_C_FLAGS: /DWIN32 /D_WINDOWS /W3
-- CMAKE_C_FLAGS_DEBUG: /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1
-- CMAKE_C_FLAGS_RELEASE: /MD /O2 /Ob2 /D NDEBUG
-- CMAKE_CXX_FLAGS: /DWIN32 /D_WINDOWS /W3 /GR /EHsc
-- CMAKE_BUILD_TYPE: Debug
-- BUILD_SHARED_LIBS:
-- CMAKE_C_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/c
l.exe
-- CMAKE_CXX_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin
/cl.exe
-- CMAKE_COMPILER_IS_GNUCC:
-- CMAKE_COMPILER_IS_GNUCXX :
-- CMAKE_AR:
-- CMAKE_RANLIB:
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/bzpl46/sim/sandbox/AE3007/C2



3) import the project into Eclipse, right click on the project, go to Properties -> C/C++ General -> Paths and Symbols and notice that there are no symbols defined. There is not even a Symbols tab which is typically the case for a valid CDT project.
No tags attached.
? toolchain_windows_vsc.cmake (2,208) 2015-05-29 14:56
https://public.kitware.com/Bug/file/5465/toolchain_windows_vsc.cmake
Issue History
2015-05-29 14:56Anthony EtteNew Issue
2015-05-29 14:56Anthony EtteFile Added: toolchain_windows_vsc.cmake
2015-06-13 16:10Alex NeundorfAssigned To => Alex Neundorf
2015-06-13 16:10Alex NeundorfStatusnew => assigned
2015-06-15 17:10Alex NeundorfNote Added: 0038930
2015-06-16 08:27Brad KingNote Added: 0038932
2015-08-14 05:43Gregor JasnyNote Added: 0039281
2015-08-18 16:32Gregor JasnyNote Added: 0039302
2015-08-20 10:54Brad KingNote Added: 0039308
2015-08-20 11:16Gregor JasnyAssigned ToAlex Neundorf => Gregor Jasny
2015-08-21 09:28Brad KingStatusassigned => resolved
2015-08-21 09:28Brad KingResolutionopen => fixed
2015-08-21 09:28Brad KingFixed in Version => CMake 3.4
2015-08-21 09:28Brad KingTarget Version => CMake 3.4
2016-01-04 11:52Robert MaynardNote Added: 0040126
2016-01-04 11:52Robert MaynardStatusresolved => closed

Notes
(0038930)
Alex Neundorf   
2015-06-15 17:10   
Are there command line flags for cl so it prints its predefined macros, built-in include search dirs, etc. (as it is done now for gcc etc.) ?
(0038932)
Brad King   
2015-06-16 08:27   
Re 0015597:0038930: No. The MSVC "cl" compiler has no builtin include search dirs. It always reads them from the INCLUDE environment variable which is set by the IDE or at the command prompt. In the VS IDE generator case CMake runs without this environment set to the include directories are not available.

The only way to reliably detect this information at CMake time is in some kind of try_compile project. CMakeDetermineCompilerABI does this for example.
(0039281)
Gregor Jasny   
2015-08-14 05:43   
How about the following fix?
https://github.com/gjasny/CMake/commit/1771e2638c8915370d50dbaa28f06ca7a20f31a6 [^]

I'm not sure if I should manually split the content of the environment variable at ';' and convert each entry from native to cmake paths.
(0039302)
Gregor Jasny   
2015-08-18 16:32   
I pushed this patch to sublime-msvc-includes topic
(0039308)
Brad King   
2015-08-20 10:54   
Re 0015597:0039302: Merged to 'next' for testing:

 Extra Generator: Populate MSVC system include paths from environment
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c66835fc [^]
(0040126)
Robert Maynard   
2016-01-04 11:52   
Closing resolved issues that have not been updated in more than 4 months.