CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-12T13:04:10-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17089pkg_check_modules with "::" in prefix2017-10-12T13:04:10-04:00chuck cranorpkg_check_modules with "::" in prefixI have a CMakeLists.txt statement that works with cmake 2.8.12.2 and 3.7.2
but fails with 3.9.0:
<pre>
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
I get error "syntax error, unexpected cal_SYMBOL, expecting } (36)"
I'm no...I have a CMakeLists.txt statement that works with cmake 2.8.12.2 and 3.7.2
but fails with 3.9.0:
<pre>
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
I get error "syntax error, unexpected cal_SYMBOL, expecting } (36)"
I'm not getting any backward compat warnings, so I wonder if it should work
with 3.9.0?
My coworker says he is also seeing the error with 3.8.2.
I made a simple test for this:
<pre>
cmake_minimum_required (VERSION 2.8.12)
project (TEST)
find_package(PkgConfig REQUIRED)
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
Here is some sample output for the 3 cmake versions noted above:
<pre>
chuck@h0:/tmp/test/b % cat ../CMakeLists.txt
cmake_minimum_required (VERSION 2.8.12)
project (TEST)
find_package(PkgConfig REQUIRED)
pkg_check_modules ("glog::glog" REQUIRED libglog)
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % cmake --version
cmake version 3.9.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).
chuck@h0:/tmp/test/b % cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
CMake Error at /tmp/cmake/share/cmake-3.9/Modules/FindPkgConfig.cmake:587 (if):
Syntax error in cmake code at
/tmp/cmake/share/cmake-3.9/Modules/FindPkgConfig.cmake:587
when parsing string
${__pkg_config_arguments_glog::glog}
syntax error, unexpected cal_SYMBOL, expecting } (36)
Call Stack (most recent call first):
CMakeLists.txt:4 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
See also "/tmp/test/b/CMakeFiles/CMakeOutput.log".
chuck@h0:/tmp/test/b % rm -rf *
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % /usr/bin/cmake --version
cmake version 2.8.12.2
chuck@h0:/tmp/test/b % /usr/bin/cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'libglog'
-- found libglog, version 0.3.3
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/b
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % rm -rf *
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % /proj/TableFS/data/travis14/cache/bin/cmake --version
cmake version 3.7.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
chuck@h0:/tmp/test/b % /proj/TableFS/data/travis14/cache/bin/cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libglog'
-- Found libglog, version 0.3.3
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/b
chuck@h0:/tmp/test/b %
</pre>https://gitlab.kitware.com/cmake/cmake/-/issues/17088Unexpected cmake log in VC2017-08-28T13:02:06-04:00DrPepperJoUnexpected cmake log in VCWhen running a custom command to copy files I get this message in my compilation log.
```
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel...When running a custom command to copy files I get this message in my compilation log.
```
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd
```
This doesn't trigger a compilation error. Not sure if this is expected behavior.https://gitlab.kitware.com/cmake/cmake/-/issues/17084Allow to query meta-fields used when compiling / linking2017-07-20T09:45:18-04:00nolangeAllow to query meta-fields used when compiling / linkingCompilation is controlled by referencing some fields that are generated from various sources. For example: `<CMAKE_C_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>`.
what I would like to propose is a function (and po...Compilation is controlled by referencing some fields that are generated from various sources. For example: `<CMAKE_C_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>`.
what I would like to propose is a function (and possibly generator expression) that allows to query those values just as cmake would do during compilation(/linking).
This relevant if you for example need the used include paths, in my specific example I tried to use the new `doxygen_add_docs` function, but I failed to be able to fetch the include paths from the used libraries.
It would be possible to read the `INTERFACE_INCLUDE_DIRECTORIES` for all linked libraries... but those could be complex generator expressions (eq. BUILD_INTERFACE/INSTALL_INTERFACE) that cant be directly used.
For such use-cases a function like `query_target_metafield(VARNAME TARGET FIELD)` would be really practical, it could extract this information directly like CMake does when compiling/linking (now ignoring that some sourcefiles could possibly add properties). Quite possible the function would need an argument to specify language, but there should be automatisms to use the target language when missing (same way the language for linking is deduced) - this should cover most usecases.https://gitlab.kitware.com/cmake/cmake/-/issues/17083cmake-gui makes CMakeCache.txt before a menu is presented (How to set -std=gn...2017-08-03T10:37:07-04:00mick-p1982cmake-gui makes CMakeCache.txt before a menu is presented (How to set -std=gnu++11?)cmake-gui is nice, it gives you browsing buttons. But as damn near as I can tell, it only actually runs cmake one time.... and it does so before it's possible to see a menu or configure anything??? Am I stupid, or is cmake-gui stupid?
W...cmake-gui is nice, it gives you browsing buttons. But as damn near as I can tell, it only actually runs cmake one time.... and it does so before it's possible to see a menu or configure anything??? Am I stupid, or is cmake-gui stupid?
Why is there not an option to always regenerate CMakeCache.txt, and why is that not the default?
Consider, how does a user set the C++ standard? If it's set after Configure, then the Makefile ignores the setting if it's based on something in CMakeCache.txt. Like in my case, a check for the existence of C++'s nullptr.https://gitlab.kitware.com/cmake/cmake/-/issues/17081Fully support add_custom_command (with PRE_BUILD/POST_BUILD) with OBJECT-libr...2019-03-26T08:40:17-04:00Deniz BahadirFully support add_custom_command (with PRE_BUILD/POST_BUILD) with OBJECT-librariesCurrently (with **CMake 3.9-rc6**), when trying to add a custom build-command to an OBJECT-library cmaking fails with the following error message:
```
(add_custom_command):
Target "MyProject_OBJECTS" is an OBJECT library that may not
...Currently (with **CMake 3.9-rc6**), when trying to add a custom build-command to an OBJECT-library cmaking fails with the following error message:
```
(add_custom_command):
Target "MyProject_OBJECTS" is an OBJECT library that may not
have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```
The important sections of the associated `CMakeFile.txt` look like this:
```cmake
set ( SOURCE_FILES
# ... several C++-source files
)
add_library( ${PROJECT_NAME}_OBJECTS OBJECT
${SOURCE_FILES}
)
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND bash -c "for i in $(echo '$<TARGET_OBJECTS:${PROJECT_NAME}_OBJECTS>' | tr '[;]' ' '); do objcopy --compress-debug-sections $i; done"
COMMENT "Compress debug-sections of object-files"
VERBATIM
)
```
It would be great if OBJECT-libraries would fully support this ("build-event") form of `add_custom_command`.
Additionally, if using Ninja-generator it would be great if Ninja would not try to rebuild the modified object-files after the `POST_BUILD` step. (As Ninja compares hashes of object-files to check if it needs to rebuilds these object-files, it should use as original hash the one created **after** the custom `POST_BUILD` step.)
For further information see this conversation on the CMake mailing-list: http://cmake.3232098.n2.nabble.com/How-to-get-list-of-generated-object-files-of-OBJECT-library-td7595824.html
Refs: #14778https://gitlab.kitware.com/cmake/cmake/-/issues/17077Optimisation flags in CMAKE_C_FLAGS/CMAKE_CXX_FLAGS should take precedence ov...2017-07-18T09:38:32-04:00Fabian RennOptimisation flags in CMAKE_C_FLAGS/CMAKE_CXX_FLAGS should take precedence over flags set by cmake via CMAKE_BUILD_TYPE=Release/CMAKE_BUILD_TYPE=DebugWhen using CMAKE_BUILD_TYPE=Release/CMAKE_BUILD_TYPE=Debug, cmake will automatically append optimisation flags to the compiler invocation (-O2 in release builds for makefiles, for example). However, these will always override any optimis...When using CMAKE_BUILD_TYPE=Release/CMAKE_BUILD_TYPE=Debug, cmake will automatically append optimisation flags to the compiler invocation (-O2 in release builds for makefiles, for example). However, these will always override any optimisation flags specified in CMAKE_C_FLAGS/CMAKE_CXX_FLAGS. This behaviour seems confusing to me. If the user manually specifies optimisation flags in CMAKE_C_FLAGS/CMAKE_CXX_FLAGS these should override any flags that cmake will attempt to set via CMAKE_BUILD_TYPE.https://gitlab.kitware.com/cmake/cmake/-/issues/17075ninja cannot erase folder with more than 1 generated file inside2019-06-07T05:20:07-04:00Norbert Pfeilerninja cannot erase folder with more than 1 generated file insideArch with CMake 3.8.2.
```
add_custom_command(OUTPUT ${foo_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${foo_dir}
)
add_custom_target(foo_dir_target DEPENDS ${foo_dir})
add_custom_command(OUTPUT ${foo_dir}/foo.cpp
COMMAND ${...Arch with CMake 3.8.2.
```
add_custom_command(OUTPUT ${foo_dir}
COMMAND ${CMAKE_COMMAND} -E make_directory ${foo_dir}
)
add_custom_target(foo_dir_target DEPENDS ${foo_dir})
add_custom_command(OUTPUT ${foo_dir}/foo.cpp
COMMAND ${CMAKE_COMMAND} -E touch ${foo_dir}/foo.cpp
DEPENDS foo_dir_target
)
add_custom_command(OUTPUT ${foo_dir}/foo2.cpp
COMMAND ${CMAKE_COMMAND} -E touch ${foo_dir}/foo2.cpp
DEPENDS foo_dir_target
)
```
`mkdir build; cd build; cmake -G Ninja ..; cmake --build .; cmake --build . --target clean;`
>ninja: error: remove(foo): Directory not empty
[cmake-ninja-folder-remove.zip](/uploads/26437a0b23a62838c34e28453318df0d/cmake-ninja-folder-remove.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/17073Running install target with root privilages breaks Ninja builds2017-08-10T08:57:32-04:00Christoph PohlRunning install target with root privilages breaks Ninja buildsA "common pattern" for a library is to run `make` and then `sudo make install`. This works splendidly with CMake. However, when using Ninja as the underlying build system, `sudo ninja install` changes the owner of `.ninja_log` to root. S...A "common pattern" for a library is to run `make` and then `sudo make install`. This works splendidly with CMake. However, when using Ninja as the underlying build system, `sudo ninja install` changes the owner of `.ninja_log` to root. Subsequent invocations of `ninja` than fail with
ninja: error: opening build log: Permission denied
Just deleting the file afterwards seems fine, but this is not the way to go, right?https://gitlab.kitware.com/cmake/cmake/-/issues/17072mingw32-make is "Deleting primary custom command output because another outpu...2017-07-20T22:15:28-04:00Patrick Storzmingw32-make is "Deleting primary custom command output because another output does not exist"While creating the testcase for #17071 I found a strange issue with mingw32-make. For a custom command like
```
add_custom_command(
OUTPUT
${CMAKE_BINARY_DIR}/version.h
${CMAKE_BINARY_DIR}/hello.rc
non-existin...While creating the testcase for #17071 I found a strange issue with mingw32-make. For a custom command like
```
add_custom_command(
OUTPUT
${CMAKE_BINARY_DIR}/version.h
${CMAKE_BINARY_DIR}/hello.rc
non-existing.txt # force to execute on every build
COMMAND
${CMAKE_COMMAND} [...]
```
which is supposed to create `version.h` and `hello.rc` (while `non-existing.txt` is actually not created but should force the command to run on every build) mingw32-make decides to delete `version.h` after successfully creating it because it's missing the non-existing file!
Full output of mingw32-make for the testcase: [test.zip](/uploads/9efa48d142c8083b696daa0dc58aa1e8/test.zip)
```
$ VERBOSE=1 mingw32-make
C:\msys64\mingw64\bin\cmake.exe -HE:\test -BE:\test\build --check-build-system CMakeFiles\Makefile.cmake 0
C:\msys64\mingw64\bin\cmake.exe -E cmake_progress_start E:\test\build\CMakeFiles E:\test\build\CMakeFiles\progress.marks
C:/msys64/mingw64/bin/mingw32-make -f CMakeFiles\Makefile2 all
mingw32-make[1]: Entering directory 'E:/test/build'
C:/msys64/mingw64/bin/mingw32-make -f CMakeFiles\hello.dir\build.make CMakeFiles/hello.dir/depend
mingw32-make[2]: Entering directory 'E:/test/build'
[ 25%] Generating version.h, hello.rc, non-existing.txt
C:\msys64\mingw64\bin\cmake.exe -DSOURCE_DIR=E:/test -DBINARY_DIR=E:/test/build -P E:/test/version.cmake
C:\msys64\mingw64\bin\cmake.exe -E cmake_depends "MinGW Makefiles" E:\test E:\test E:\test\build E:\test\build E:\test\build\CMakeFiles\hello.dir\DependInfo.cmake --color=
Deleting primary custom command output "E:/test/build/version.h" because another output "E:/test/build/non-existing.txt" does not exist.
Dependee "E:\test\build\CMakeFiles\hello.dir\DependInfo.cmake" is newer than depender "E:/test/build/CMakeFiles/hello.dir/depend.internal".
Dependee "E:/test/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "E:/test/build/CMakeFiles/hello.dir/depend.internal".
Scanning dependencies of target hello
mingw32-make[2]: Leaving directory 'E:/test/build'
C:/msys64/mingw64/bin/mingw32-make -f CMakeFiles\hello.dir\build.make CMakeFiles/hello.dir/build
mingw32-make[2]: Entering directory 'E:/test/build'
[ 50%] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
C:\msys64\mingw64\bin\g++.exe @CMakeFiles/hello.dir/includes_CXX.rsp -o CMakeFiles\hello.dir\hello.cpp.obj -c E:\test\hello.cpp
E:\test\hello.cpp:2:9: fatal error: version.h: No such file or directory
#include<version.h>
^~~~~~~~~~~
compilation terminated.
mingw32-make[2]: *** [CMakeFiles\hello.dir\build.make:73: CMakeFiles/hello.dir/hello.cpp.obj] Error 1
mingw32-make[2]: Leaving directory 'E:/test/build'
mingw32-make[1]: *** [CMakeFiles\Makefile2:67: CMakeFiles/hello.dir/all] Error 2
mingw32-make[1]: Leaving directory 'E:/test/build'
mingw32-make: *** [Makefile:83: all] Error 2
```
Note the line `Deleting primary custom command output "E:/test/build/version.h" because another output "E:/test/build/non-existing.txt" does not exist.`
Interestingly one can trick cmake/mingw32-make into working by simply switching the order of the outputs like
```
add_custom_command(
OUTPUT
non-existing.txt # force to execute on every build
${CMAKE_BINARY_DIR}/version.h
${CMAKE_BINARY_DIR}/hello.rc
COMMAND
${CMAKE_COMMAND} [...]
```
I don't know if this is "by design" or a limitation, but it certainly seems strange...
**System information**
cmake 3.8.2 and mingw32-make 4.2.1 on MSYS2
(specifically mingw-w64-x86_64-cmake 3.8.2-2 and mingw-w64-x86_64-make 4.2.1-1)https://gitlab.kitware.com/cmake/cmake/-/issues/17071Ninja does not always rebuild resource files (*.rc) when they were changed2021-06-15T18:27:22-04:00Patrick StorzNinja does not always rebuild resource files (*.rc) when they were changedI have a project with a custom command that updates the current version number (based on git commit hash) on every build and updates two files (a header file and a resource file) via `configure_file`.
The custom command is added with ...I have a project with a custom command that updates the current version number (based on git commit hash) on every build and updates two files (a header file and a resource file) via `configure_file`.
The custom command is added with `add_custom_command` and looks something like this:
```
add_custom_command(
OUTPUT
non-existing.txt # force to execute on every build
version.h
program.rc
COMMAND
${CMAKE_COMMAND} update_version.cmake)
```
The idea is that the current version is accessible from within the code but is also saved into the executable files version information.
A minimal sample project showing the issue is attached. [test.zip](/uploads/eb3cbeb7465662056dfc36eb5e674fde/test.zip)
**Problem**
When I use `cmake -G Ninja` to configure the project and subsequently run `ninja` the RC object is only built every second run (i.e. the change to the .rc file occuring on every run is not detected by the build system immediately). This is highlighted by the following output:
```
$ ninja
[1/5] Generating non-existing.txt, version.h, hello.rc
[2/5] cmd.exe /c
[3/5] Building RC object CMakeFiles/hello.dir/hello.rc.obj
[4/5] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
[5/5] Linking CXX executable hello.exe
$ ninja
[1/3] Generating non-existing.txt, version.h, hello.rc
[2/3] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
[3/3] Linking CXX executable hello.exe
$ ninja
[1/4] Generating non-existing.txt, version.h, hello.rc
[2/4] Building RC object CMakeFiles/hello.dir/hello.rc.obj
[3/4] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
[4/4] Linking CXX executable hello.exe
$ ninja
[1/3] Generating non-existing.txt, version.h, hello.rc
[2/3] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
[3/3] Linking CXX executable hello.exe
$ ninja
[1/4] Generating non-existing.txt, version.h, hello.rc
[2/4] Building RC object CMakeFiles/hello.dir/hello.rc.obj
[3/4] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
[4/4] Linking CXX executable hello.exe
```
I also tested `cmake -G "MinGW Makefiles` and `mingw32-make` which rebuilds both the .rc file and the .cpp file in every run.
**Environment information**
cmake 3.8.2 and Ninja 1.7.2 on MSYS2
(specifically mingw-w64-x86_64-cmake 3.8.2-2 and mingw-w64-i686-ninja 1.7.2-1)
However standalone cmake 3.9.0-rc6 with standalone ninja version 1.7.2 is also affected.
Interestingly and older standalone version cmake 3.7.2 seems not to have had this problem.https://gitlab.kitware.com/cmake/cmake/-/issues/17070Filter linker inputs? ld returns "file not recognized: File format not recogn...2017-07-15T12:30:49-04:00mick-p1982Filter linker inputs? ld returns "file not recognized: File format not recognized" (e.g. h->gch files)I'm trying to realize precompiled-headers via an approach where a new language is established. I keep running into one hitch after the next as I try to generalize the process to be more complete and professional.
In this instance, I wou...I'm trying to realize precompiled-headers via an approach where a new language is established. I keep running into one hitch after the next as I try to generalize the process to be more complete and professional.
In this instance, I would like to include the header in the project's sources, so that end-users see all of the source code in the generated output.
CMake 3.9.0 sees the precompiled-header and since it's assigned to this "language" it generates a build rule, that puts a dependency on the build-target for the GCH file that the new "language" generates.
First, let me say, that I think giving headers to the targets in this way causes all kinds of problems, but this is how CMake works, so.
I've tried modifying the EXTENSIONS variables from here ( https://cmake.org/Wiki/CMake_Useful_Variables#Variables_not_listed_here ) but have not achieved anything.
The problem is CMake passes the GCH via the linker inputs. I can't find a mechanism to have it be ignored. I realize that probably only Visual Studio retains the headers, however I would like to not have to wrap conditions around their inclusion, or assume knowledge about the build environment.
Thoughts? Fixes? (Maybe this is not an Issue proper, but I'm stumped and unsure who to turn to.) Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/17068MSVC toolset 14.1+: Set /permissive- when CXX_EXTENSIONS==OFF?2023-06-13T02:02:48-04:00Patrik HuberMSVC toolset 14.1+: Set /permissive- when CXX_EXTENSIONS==OFF?VS2017 (both cl (compiler) version 19.10 and 19.11) have a `/permissive-` flag that puts them into standard-conforming mode, i.e. disallowing MSVC-specific C++ language extensions. It may make sense to set this flag if `CMAKE_CXX_EXTENSI...VS2017 (both cl (compiler) version 19.10 and 19.11) have a `/permissive-` flag that puts them into standard-conforming mode, i.e. disallowing MSVC-specific C++ language extensions. It may make sense to set this flag if `CMAKE_CXX_EXTENSIONS` is set to `OFF`?
There is also [`-Za`](https://docs.microsoft.com/en-us/cpp/build/reference/za-ze-disable-language-extensions) and [`-Zc`](https://docs.microsoft.com/en-us/cpp/build/reference/zc-conformance), I am not sure whether that is already handled by CMake and what the exact difference to `/permissive-` is.
This discussion emerged out of #16482.https://gitlab.kitware.com/cmake/cmake/-/issues/17067Trying to add_test using cmd.exe2022-06-13T10:27:08-04:00Ákos TomposTrying to add_test using cmd.exeUsing cmake version 3.8.1
The following really short CMakeLists.txt file should add a single test that runs cmd /?. As running the help returns failure it should fail and with the --output-on-failure option you can see the output.
```
...Using cmake version 3.8.1
The following really short CMakeLists.txt file should add a single test that runs cmd /?. As running the help returns failure it should fail and with the --output-on-failure option you can see the output.
```
enable_testing()
add_test(NAME Test
COMMAND cmd /?
WORKING_DIRECTORY ".")
```
executing the test:
```
cmake . && ctest -C Debug --output-on-failure
```
The result is surprising:
```
Start 1: Test
1/1 Test #1: Test .............................***Failed 0.02 sec
Creates a directory.
MKDIR [drive:]path
MD [drive:]path
If Command Extensions are enabled MKDIR changes as follows:
MKDIR creates any intermediate directories in the path, if needed.
For example, assume \a does not exist then:
mkdir \a\b\c\d
is the same as:
mkdir \a
chdir \a
mkdir b
chdir b
mkdir c
chdir c
mkdir d
which is what you would have to type if extensions were disabled.
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.03 sec
The following tests FAILED:
1 - Test (Failed)
Errors while running CTest
```
Which is the help for the `md` command. And indeed the `ctest` runs `md` instead of `cmd`
It somehow omits the first character of the command. It doesn't do that with other commands though.https://gitlab.kitware.com/cmake/cmake/-/issues/17066Using clang in cross-compilation mode doesn't generate proper system include ...2017-07-14T10:22:18-04:00Jacek SwierkUsing clang in cross-compilation mode doesn't generate proper system include headers and macros for some IDEsCodeBlocks and Eclipse generators (as well as the other IDEs that use them like QtCreator which uses CodeBlocks generator) have an additional module CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake that calls the compiler t...CodeBlocks and Eclipse generators (as well as the other IDEs that use them like QtCreator which uses CodeBlocks generator) have an additional module CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake that calls the compiler to find out system includes and defines. The problem is that the command that's called is incomplete for clang compilator that's run with arguments like --target, --gcc-toolchain or --sysroot. Moreover, if the CMAKE_<LANG>_COMPILER_ARG1 will include more than one argument the current module will not work correctly. Because of that, previously mentioned IDEs do not see certain system includes.
I prepared a quick patch that could be a base for official changes:
[CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.patch](/uploads/9ade6227a1f26ae18157bae7a1c21be1/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/17065Set __cplusplus value for C++11, EclipseCDT42017-12-27T10:09:37-05:00RobertSet __cplusplus value for C++11, EclipseCDT4CMake version: 3.5.1
Eclipse version: Neon.3 Release (4.6.3), Build id: 20170314-1500
When creating a project with
```
set_target_properties(TargetName PROPERTIES
CXX_STANDARD 11
CXX_STANDARD_REQUIRED ON
CXX_EXTE...CMake version: 3.5.1
Eclipse version: Neon.3 Release (4.6.3), Build id: 20170314-1500
When creating a project with
```
set_target_properties(TargetName PROPERTIES
CXX_STANDARD 11
CXX_STANDARD_REQUIRED ON
CXX_EXTENSIONS OFF
)
```
and generating the project files with the generator "Eclipse CDT4 - Unix Makefiles":
After opening the project with Eclipse, the source code is not treated as C++11 by the IDE.
Compiling works perfectly, but the built-in auto-complete and source parser show all C++11 features as errors because the symbol __cplusplus is set to 199711L per default.
Changing the symbol after creating the project fixes this issue.
Is it possible to already set the __cplusplus symbol to 201103L when generating with the C++11 standard set (and maybe other standards to their respective values)?
EDIT:
Given the test project
[Test.tar.gz](/uploads/f7c564179aa33d14ab4b2e3eb42e845d/Test.tar.gz)
Create a folder on the same level as the project folder:
```
|-Test
|-Test-build
```
Inside of Test-build execute
```
cmake -G"Eclipse CDT4 - Unix Makefiles" ./../Test/
```
Open up the Eclipse IDE (C++) and import the project folder (Test-build)into the workspace:
* File -> Import...
* General -> Existing Projects into Workspace
* Click Next -> Select root directory -> Browse and select the "Test-build" folder
The resulting screen:
![image](/uploads/6e204851d77be2bf156e9b46a79c45ba/image.png)
The code assistant fails to parse C++11 dependent features but even though the IDE shows errors, **at this point compiling the project already works**.
The IDE shows these errors because the following is set:
* Left click on the project name -> Properties
* C/C++ Include Paths and Symbols -> the symbol __cplusplus is set to "199711L"
![image](/uploads/bedc6fa7db33e8ab4c20b4c8e7556c9e/image.png)
To fix this issue, the value has to be manually set to "201103L"
![image](/uploads/e85b75093c14fa6341f2029a4dd4cf53/image.png)
Now the Index needs to be rebuild/the project needs to be reparsed:
* Project -> C/C++ Index -> Rebuild
Which results in the IDE being able to parse/provide support for C++11 features
![image](/uploads/fd669c76aa766868a582919e85f27eed/image.png)
The expected outcome would be that an Eclipse project generated this way would have this setting already without the need to manually change the IDE symbol.https://gitlab.kitware.com/cmake/cmake/-/issues/17064Warn or error when custom commands duplicate a MAIN_DEPENDENCY2017-07-13T16:37:29-04:00Ben BoeckelWarn or error when custom commands duplicate a MAIN_DEPENDENCYThis is easy enough to hit in common code which calls `add_custom_command` deep in a call stack. CMake should be able to detect and warn or error about this. Not sure if a policy would be required for the error case since it's actually a...This is easy enough to hit in common code which calls `add_custom_command` deep in a call stack. CMake should be able to detect and warn or error about this. Not sure if a policy would be required for the error case since it's actually a broken build otherwise.
See #16580.
Cc: @brad.king @bill-hoffmanhttps://gitlab.kitware.com/cmake/cmake/-/issues/17055Support `CMAKE_EXPORT_COMPILE_COMMANDS` for all generators2017-07-12T11:00:59-04:00Thomas DickersonSupport `CMAKE_EXPORT_COMPILE_COMMANDS` for all generatorsI'm working on a libclang-based tool that requires loading some C++ files, and generates some new source files that other targets would depend on.
It would be really useful to be able to generate a `compile_commands.json` CompilationDat...I'm working on a libclang-based tool that requires loading some C++ files, and generates some new source files that other targets would depend on.
It would be really useful to be able to generate a `compile_commands.json` CompilationDatabase for a given target, rather than having to manually re-set all of the compilation flags for the script to use, but since I'm most often developing with Xcode, this is infeasible until `CMAKE_EXPORT_COMPILE_COMMANDS` is supported on other generators.https://gitlab.kitware.com/cmake/cmake/-/issues/17050Unix Makefiles vs Windows paths...2017-07-13T13:53:54-04:00Ryan C. GordonUnix Makefiles vs Windows paths...(Tested against CMake 3.8.2, prebuilt binary downloaded from cmake.org.)
When attempting to build with Mingw64, a Windows path with a drive letter on it will confuse GNU Make, producing a misleading error message. Here's a simplified te...(Tested against CMake 3.8.2, prebuilt binary downloaded from cmake.org.)
When attempting to build with Mingw64, a Windows path with a drive letter on it will confuse GNU Make, producing a misleading error message. Here's a simplified test case based on one I stumbled across in real project:
cmake_minimum_required(VERSION 3.2)
project(brokenmake)
find_library(PTHREAD_LIBRARY pthread)
add_executable(brokenmake brokenmake.c)
target_link_libraries(brokenmake ${PTHREAD_LIBRARY})
Just make a zero-byte file named "brokenmake.c" and run CMake like this:
cmake -G "Unix Makefiles" -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc .
CMake succeeds, but running "make" afterwards produces this error:
CMakeFiles/brokenmake.dir/build.make:93: *** target pattern contains no '%'. Stop.
The problem is this line in build.make:
brokenmake.exe: C:/cygwin/lib/libpthread.a
The ':' confuses GNU Make; it needs to be escaped...
brokenmake.exe: C\:/cygwin/lib/libpthread.a
...and then GNU Make works fine with this makefile (rather: it compiles and fails to link without a WinMain(), but GNU Make did the right thing at that point.)
I guess the Unix Makefile generator needs to check files for special characters (space, :, $, a few others?) and escape as appropriate?
--ryan.https://gitlab.kitware.com/cmake/cmake/-/issues/17049Crosscompiling with Clang is cumbersome2017-07-10T09:34:20-04:00nolangeCrosscompiling with Clang is cumbersomeHello,
there are several drawbacks when compiling with clang using a secondary toolchain like gcc.
There is an issue with having a separate Toolchain path, the clang/llvm path contains the compiler and several tools, while atleast the l...Hello,
there are several drawbacks when compiling with clang using a secondary toolchain like gcc.
There is an issue with having a separate Toolchain path, the clang/llvm path contains the compiler and several tools, while atleast the linker (via gcc) should be from the secondary path.
A naive toolchain fail will result in AR missing, see the attached project (a link to a crosscompiler is attached below).
See the toolchain file that is necessary to set all the variables and whether they should be picked from primary or secondary toolchain.
Also the llvm tools should be searched with and without the ${_CMAKE_TOOLCHAIN_PREFIX}.
For Cmake 3.9 the new COMPILER_RANLIB and COMPILER_AR variables have a similar issue and I attached a patch. LTO still does not work in this configuration.
There are alot of issues (see adding all those include paths, and clangs option "--gcc-toolchain" being pretty much useless), but IMHO CMake should atleast deal with finding the correct programs.
[crosscompile_clang.tar.xz](/uploads/61421b66aece199d09cf90029fc64bc6/crosscompile_clang.tar.xz)
[ARM Crosscompiler](https://developer.arm.com/open-source/gnu-toolchain/gnu-rm)
[findclangbinutils.patch](/uploads/39fc21005c745cfd92f439a5aa3de9c7/findclangbinutils.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/17043Disabling PkgConfig causes error when finding modules invokes it2017-07-08T09:37:30-04:00Aleksey N. VinogradovDisabling PkgConfig causes error when finding modules invokes itI want to configure the build with system libraries (they perfectly found by FindXXX modules).
However, on one of the system pkg-config is installed, it hints about *another* libs, and finally it crashes the build with strange errors.
T...I want to configure the build with system libraries (they perfectly found by FindXXX modules).
However, on one of the system pkg-config is installed, it hints about *another* libs, and finally it crashes the build with strange errors.
The simplest way to achieve a build is to deactivate or even uninstall pkg-config. But of course it is not so good in global scope.
Another way - define "CMAKE_DISABLE_FIND_PACKAGE_PkgConfig" as "ON".
(have tried SET (PKG_CONFIG_FOUND FALSE) and even with ..CACHE FORCE and CACHE INTERNAL - no success).
I use this method, but immediately hit with the issue: configuration fails with error - in my case 'Unknown CMake command "pkg_check_modules".' - because in all the FindXXX which uses pkgconfig the next command after find_package(PkgConfig) is invoking one of the macro/function defined there.
For the moment I hit the problem with small snippet:
macro( pkg_check_modules )
endmacro()
just after I "SET ( CMAKE_DISABLE_FIND_PACKAGE_PkgConfig ON )"
If solved the problem for me, however it still may be so if finding of a package invokes another macros from there.
I think it would be good to have a mechanism which can not just disable to find the module at all, but set the result to 'not found' - with all implicitly defined essences still active.