CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-03-23T09:40:13-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/9955qt4_automoc fails if .h and .cpp in different directories2017-03-23T09:40:13-04:00Kitware Robotqt4_automoc fails if .h and .cpp in different directoriesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9955). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9955). Further discussion may take place here.3.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/16733Add generator expressions for macOS bundle targets2017-04-03T23:02:56-04:00Kevin WojniakAdd generator expressions for macOS bundle targets`TARGET_FILE` currently for macOS bundles goes to the /Contents/MacOS/XXX file, and `TARGET_FILE_DIR` goes to the /Contents/MacOS/ directory. It would be nice if there were generator expressions that mapped to the bundle and bundle paren...`TARGET_FILE` currently for macOS bundles goes to the /Contents/MacOS/XXX file, and `TARGET_FILE_DIR` goes to the /Contents/MacOS/ directory. It would be nice if there were generator expressions that mapped to the bundle and bundle parent directory, for example `TARGET_BUNDLE` and `TARGET_BUNDLE_DIR`. Currently we have to use relative paths, like `$<TARGET_FILE_DIR:${TARGET}>/../../` which is more difficult to read.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16795Xcode generator doesn't respect SYSTEM when setting include_directories2017-04-22T11:04:29-04:00Konstantin KäferXcode generator doesn't respect SYSTEM when setting include_directoriesWhen using `target_include_directories(target SYSTEM <paths...>)`, the Make and Ninja generators use `-isystem` to pass the include directories to the compiler. Xcode has the properties `HEADER_SEARCH_PATHS` (which get passed with `-I` t...When using `target_include_directories(target SYSTEM <paths...>)`, the Make and Ninja generators use `-isystem` to pass the include directories to the compiler. Xcode has the properties `HEADER_SEARCH_PATHS` (which get passed with `-I` to the compiler), and `SYSTEM_HEADER_SEARCH_PATHS`, which uses `-isystem`. However, the Xcode generator indiscriminately [passes all paths into the `HEADER_SEARCH_PATHS`](https://gitlab.kitware.com/cmake/cmake/blob/fddd559406558a2037733e5b760e9dd04e9edfd1/Source/cmGlobalXCodeGenerator.cxx#L2048).3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16800CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH is interpreted differently if coming fr...2017-05-03T10:50:22-04:00Åke SandgrenCMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH is interpreted differently if coming from the environment compared to being set with -DCMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH are defined as ";-list of directories specifying a search path" in the documentation.
When doing
cmake -DCMAKE_INCLUDE_PATH='/patha;/pathb'
it behaves as expected.
But when set in the enviroment it...CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH are defined as ";-list of directories specifying a search path" in the documentation.
When doing
cmake -DCMAKE_INCLUDE_PATH='/patha;/pathb'
it behaves as expected.
But when set in the enviroment it doesn't. It doesn't get split on ";", instead it gets split on ":"
Having two different interpretations of those variables (and others) is confusing, especially since it doesn't seem to be documented anywhere.
Is there a reason NOT to split on ";" even when coming from the environment?3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16680When building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends ...2017-05-04T16:23:48-04:00vshashenkoWhen building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends '../' to the path givenMACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle....MACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle. The 'Resources' value seems to have a special meaning on iOS and the files are actually placed in the bundle root. But if use 'Resources/AnotherFolder', it gets prepended with '../' as well.
I've also found this message in the mailing list describing the same problem: https://cmake.org/pipermail/cmake/2016-August/064125.html3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16678ExternalProject git checkout fails when tag name matches path name2017-05-04T16:23:48-04:00David GlessnerExternalProject git checkout fails when tag name matches path nameExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate path...ExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Current branch bbb is up to date.
```
The following patch fixed it for me. I didn't look to see if other places needed a `--` separator.
```
--- /usr/share/cmake-3.6/Modules/ExternalProject.cmake 2016-09-07 09:11:58.000000000 -0500
+++ ExternalProject.cmake-3.6 2016-09-23 12:50:09.153230047 -0500
@@ -573,7 +573,7 @@
endif()
execute_process(
- COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag}
+ COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag} --
WORKING_DIRECTORY \"${work_dir}/${src_name}\"
RESULT_VARIABLE error_code
)
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16663cmake.m4 CMAKE_FIND_PACKAGE ignores any previously set flags/libs2017-05-04T16:23:48-04:00Johncmake.m4 CMAKE_FIND_PACKAGE ignores any previously set flags/libsWhen calling CMAKE_FIND_PACKAGE from the cmake.m4 file for a given package, the test of the FLAGS and LIBS variable length is non zero (test -n) and then sets the flag/lib variable to the output of the cmake --find-package.
It should ...When calling CMAKE_FIND_PACKAGE from the cmake.m4 file for a given package, the test of the FLAGS and LIBS variable length is non zero (test -n) and then sets the flag/lib variable to the output of the cmake --find-package.
It should be check with the FLAG/LIB vriable is already set to something (test -z) and only setting it to the cmake value IF it is not already set.3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/16607Process script mode eats 2 first bytes of input2017-05-04T16:23:50-04:00Paweł BylicaProcess script mode eats 2 first bytes of inputWhen process substitution is used in shell, the 2 first bytes are ignored by cmake.
Example:
cmake -P <(echo "cmake_policy(VERSION 3.6)")
will produce following error:
CMake Error at /proc/self/fd/11:1 (ake_policy):
Unk...When process substitution is used in shell, the 2 first bytes are ignored by cmake.
Example:
cmake -P <(echo "cmake_policy(VERSION 3.6)")
will produce following error:
CMake Error at /proc/self/fd/11:1 (ake_policy):
Unknown CMake command "ake_policy".
The workaround is to add 2 spaces at the beginning of the input.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16907[Regression] AUTOMOC is broken on Windows if AUTOUIC is not enabled2017-05-23T10:24:44-04:00endrift[Regression] AUTOMOC is broken on Windows if AUTOUIC is not enabledWhen trying to build a project on Windows using AUTOMOC without AUTOUIC with CMake 3.8.1, moc is not invoked and moc_compilation.cpp is not generated. I tried MSYS Makefiles, Unix Makefiles and MSVC 14 generators, but all had the same re...When trying to build a project on Windows using AUTOMOC without AUTOUIC with CMake 3.8.1, moc is not invoked and moc_compilation.cpp is not generated. I tried MSYS Makefiles, Unix Makefiles and MSVC 14 generators, but all had the same result.
This is a regression from 3.7, in which the build worked fine. Also tested in 3.8.1 on macOS and 3.8.0 on Linux, where it builds fine as well.
Minimal repro is attached. Adding `set(CMAKE_AUTOUIC ON)` before creating the target fixes the build, but should not be necessary.
[CMakeLists.txt](/uploads/873c73f7a07415526aa946dc6ee4d650/CMakeLists.txt)
[moc_test.cpp](/uploads/44b67f107c074bbda06303afd7747dd5/moc_test.cpp)
[moc_test.h](/uploads/58827f4baab52f0b7318163e157227ba/moc_test.h)3.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/16893Ninja generator doesn’t work in msys2-built cmake2017-05-26T11:17:20-04:00Norbert PfeilerNinja generator doesn’t work in msys2-built cmakeThe problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to...The problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to work with mingw-w64 which results in an inability for the generator to produce any files.
`codecvt::do_out` always returns `std::codecvt::error` when a range of more than 1 char is passed.
Changing [this condition](https://gitlab.kitware.com/cmake/cmake/blob/6b05e028f1a3afc7906908bd48d58993da02a9d9/Source/cm_codecvt.cxx#L61) to `>= 1` seems to fix it.
I’m not sure why it should work the way it currently is at all.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16917CMAKE_CXX_COMPILER_VERSION is not documented2017-05-30T09:26:23-04:00Mateusz ŁoskotCMAKE_CXX_COMPILER_VERSION is not documentedThe following variables are not documented in 3.8.1 (including the current git master/stage docs)
* `CMAKE_CXX_COMPILER_VERSION`
* `CMAKE_C_COMPILER_VERSION`The following variables are not documented in 3.8.1 (including the current git master/stage docs)
* `CMAKE_CXX_COMPILER_VERSION`
* `CMAKE_C_COMPILER_VERSION`3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16939Autogen: Visual Studio builds broken in 3.9.0-rc12017-06-07T11:08:24-04:00Brad KingAutogen: Visual Studio builds broken in 3.9.0-rc1The Qt5Autogen test fails with Visual Studio generators:
```
110: CMake Error in C:/.../Tests/QtAutogen/rccDepends/CMakeLists.txt:
110: Target "rccDepends" has source files which vary by configuration. This is
110: not supported by...The Qt5Autogen test fails with Visual Studio generators:
```
110: CMake Error in C:/.../Tests/QtAutogen/rccDepends/CMakeLists.txt:
110: Target "rccDepends" has source files which vary by configuration. This is
110: not supported by the "Visual Studio 15 2017" generator.
110:
110: Config "Debug":
110:
110: C:/.../Tests/QtAutogen/rccDepends/main.cpp
110: C:/.../Tests/Qt5Autogen/rccDepends/res1.qrc
110: C:/.../Tests/Qt5Autogen/rccDepends/res2.qrc
110: C:/.../Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp
110: C:/.../Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp
110:
110: Config "Release":
110:
110: C:/.../Tests/QtAutogen/rccDepends/main.cpp
110: C:/.../Tests/Qt5Autogen/rccDepends/res1.qrc
110: C:/.../Tests/Qt5Autogen/rccDepends/res2.qrc
110: C:/.../Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp
110: C:/.../Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp
...
110: CMake Error at C:/.../Tests/QtAutogen/rccDepends/CMakeLists.txt:29 (add_executable):
110: Cannot find source file:
110:
110: C:/.../Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_.cpp
110:
110: Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
110: .hxx .in .txx
110:
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16887RunCMake.GNUInstallDirs test fails on FreeBSD2017-06-09T11:04:04-04:00François BisseyRunCMake.GNUInstallDirs test fails on FreeBSDIt fails because `CMAKE_INSTALL_MANDIR` is `man` not `share/man` similarly with `CMAKE_INSTALL_FULL_MANDIR`. Typical error output
```
298: expect-err> ^CMAKE_INSTALL_BINDIR='bin'
298: expect-err> CMAKE_INSTALL_DATADIR='share'
298: ...It fails because `CMAKE_INSTALL_MANDIR` is `man` not `share/man` similarly with `CMAKE_INSTALL_FULL_MANDIR`. Typical error output
```
298: expect-err> ^CMAKE_INSTALL_BINDIR='bin'
298: expect-err> CMAKE_INSTALL_DATADIR='share'
298: expect-err> CMAKE_INSTALL_DATAROOTDIR='share'
298: expect-err> CMAKE_INSTALL_DOCDIR='share/doc/UsrLocal'
298: expect-err> CMAKE_INSTALL_INCLUDEDIR='include'
298: expect-err> CMAKE_INSTALL_INFODIR='share/info'
298: expect-err> CMAKE_INSTALL_LIBDIR='(lib|lib64)'
298: expect-err> CMAKE_INSTALL_LIBEXECDIR='libexec'
298: expect-err> CMAKE_INSTALL_LOCALEDIR='share/locale'
298: expect-err> CMAKE_INSTALL_LOCALSTATEDIR='var'
298: expect-err> CMAKE_INSTALL_MANDIR='share/man'
298: expect-err> CMAKE_INSTALL_SBINDIR='sbin'
298: expect-err> CMAKE_INSTALL_SHAREDSTATEDIR='com'
298: expect-err> CMAKE_INSTALL_SYSCONFDIR='etc'
298: expect-err> CMAKE_INSTALL_FULL_BINDIR='/usr/local/bin'
298: expect-err> CMAKE_INSTALL_FULL_DATADIR='/usr/local/share'
298: expect-err> CMAKE_INSTALL_FULL_DATAROOTDIR='/usr/local/share'
298: expect-err> CMAKE_INSTALL_FULL_DOCDIR='/usr/local/share/doc/UsrLocal'
298: expect-err> CMAKE_INSTALL_FULL_INCLUDEDIR='/usr/local/include'
298: expect-err> CMAKE_INSTALL_FULL_INFODIR='/usr/local/share/info'
298: expect-err> CMAKE_INSTALL_FULL_LIBDIR='/usr/local/(lib|lib64)'
298: expect-err> CMAKE_INSTALL_FULL_LIBEXECDIR='/usr/local/libexec'
298: expect-err> CMAKE_INSTALL_FULL_LOCALEDIR='/usr/local/share/locale'
298: expect-err> CMAKE_INSTALL_FULL_LOCALSTATEDIR='/usr/local/var'
298: expect-err> CMAKE_INSTALL_FULL_MANDIR='/usr/local/share/man'
298: expect-err> CMAKE_INSTALL_FULL_SBINDIR='/usr/local/sbin'
298: expect-err> CMAKE_INSTALL_FULL_SHAREDSTATEDIR='/usr/local/com'
298: expect-err> CMAKE_INSTALL_FULL_SYSCONFDIR='/usr/local/etc'$
298:
298: Actual stderr:
298:
298: actual-err> CMAKE_INSTALL_BINDIR='bin'
298: actual-err> CMAKE_INSTALL_DATADIR='share'
298: actual-err> CMAKE_INSTALL_DATAROOTDIR='share'
298: actual-err> CMAKE_INSTALL_DOCDIR='share/doc/UsrLocal'
298: actual-err> CMAKE_INSTALL_INCLUDEDIR='include'
298: actual-err> CMAKE_INSTALL_INFODIR='info'
298: actual-err> CMAKE_INSTALL_LIBDIR='lib'
298: actual-err> CMAKE_INSTALL_LIBEXECDIR='libexec'
298: actual-err> CMAKE_INSTALL_LOCALEDIR='share/locale'
298: actual-err> CMAKE_INSTALL_LOCALSTATEDIR='var'
298: actual-err> CMAKE_INSTALL_MANDIR='man'
298: actual-err> CMAKE_INSTALL_SBINDIR='sbin'
298: actual-err> CMAKE_INSTALL_SHAREDSTATEDIR='com'
298: actual-err> CMAKE_INSTALL_SYSCONFDIR='etc'
298: actual-err> CMAKE_INSTALL_FULL_BINDIR='/usr/local/bin'
298: actual-err> CMAKE_INSTALL_FULL_DATADIR='/usr/local/share'
298: actual-err> CMAKE_INSTALL_FULL_DATAROOTDIR='/usr/local/share'
298: actual-err> CMAKE_INSTALL_FULL_DOCDIR='/usr/local/share/doc/UsrLocal'
298: actual-err> CMAKE_INSTALL_FULL_INCLUDEDIR='/usr/local/include'
298: actual-err> CMAKE_INSTALL_FULL_INFODIR='/usr/local/info'
298: actual-err> CMAKE_INSTALL_FULL_LIBDIR='/usr/local/lib'
298: actual-err> CMAKE_INSTALL_FULL_LIBEXECDIR='/usr/local/libexec'
298: actual-err> CMAKE_INSTALL_FULL_LOCALEDIR='/usr/local/share/locale'
298: actual-err> CMAKE_INSTALL_FULL_LOCALSTATEDIR='/usr/local/var'
298: actual-err> CMAKE_INSTALL_FULL_MANDIR='/usr/local/man'
298: actual-err> CMAKE_INSTALL_FULL_SBINDIR='/usr/local/sbin'
298: actual-err> CMAKE_INSTALL_FULL_SHAREDSTATEDIR='/usr/local/com'
298: actual-err> CMAKE_INSTALL_FULL_SYSCONFDIR='/usr/local/etc'
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16942When Building CMake with VS2017, all compiler features are detected as missing2017-06-09T11:04:04-04:00Walter GrayWhen Building CMake with VS2017, all compiler features are detected as missingIn cm_cxx_features.cmake, the conditional `OUTPUT MATCHES "[Ww]arning"` always returns true.
I'm unsure if this impacts other versions at the moment.In cm_cxx_features.cmake, the conditional `OUTPUT MATCHES "[Ww]arning"` always returns true.
I'm unsure if this impacts other versions at the moment.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16944IPO: Stops to work when enabling ASM2017-06-15T10:05:05-04:00nolangeIPO: Stops to work when enabling ASMCMake will report that the compiler doesnt support IPO, even if it does. I suspect this is related to the `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` setting.
Looking at the CMakeCache.txt, the paths to *prefix-*gcc-ar and *prefix-...CMake will report that the compiler doesnt support IPO, even if it does. I suspect this is related to the `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` setting.
Looking at the CMakeCache.txt, the paths to *prefix-*gcc-ar and *prefix-*gcc-ranlib are correctly detected (*prefix-*gcc-nm is missing)
This happens with an arm-none-eabi compiler and CMake 3.9.0rc1 on linux. The compiler requires a linkerscript for executables.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16974Documentation: Help/manual/cmake-compile-features.7.rst#L337 should mention M...2017-06-16T09:34:11-04:00Jano SvitokDocumentation: Help/manual/cmake-compile-features.7.rst#L337 should mention MSVC 2017I suppose that the CXX_STANDARD et al. are supported for the newest version as well.
Maybe the wording should be "2010 and newer".I suppose that the CXX_STANDARD et al. are supported for the newest version as well.
Maybe the wording should be "2010 and newer".3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16993CUDA: Visual Studio integration bugs prior to 8.0.612017-06-21T08:36:06-04:00Robert MaynardCUDA: Visual Studio integration bugs prior to 8.0.61When building shared libraries using Visual Studio the CUDA msbuild section are missing the `<target_name>_EXPORTS` define.
This looks to be caused by ``cmVisualStudio10TargetGenerator`` not storing ``target->GetExportMacro()` as a de...When building shared libraries using Visual Studio the CUDA msbuild section are missing the `<target_name>_EXPORTS` define.
This looks to be caused by ``cmVisualStudio10TargetGenerator`` not storing ``target->GetExportMacro()` as a define for the CUDA language.
Discussed on mailing list:
* June 2017: [Missing \<target\>_EXPORTS definition in CUDA host compilation](https://cmake.org/pipermail/cmake/2017-June/065597.html)
3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17011Calling target_compile_features with a cxx feature on a C project cause segfault2017-06-27T09:20:34-04:00Alex TennantCalling target_compile_features with a cxx feature on a C project cause segfaultNot a big deal, but not how I'd expect Cmake to handle this scenario.
cmake version 3.8.1, OSX 10.12.5
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.8.1)
project(Example LANGUAGES C)
add_library(Example dummy.c)
targe...Not a big deal, but not how I'd expect Cmake to handle this scenario.
cmake version 3.8.1, OSX 10.12.5
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.8.1)
project(Example LANGUAGES C)
add_library(Example dummy.c)
target_compile_features(Example PRIVATE cxx_enum_forward_declarations)
```
Result:
Segmentation fault: 113.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/15441Xcode generator does not generate scheme2017-06-27T15:00:50-04:00Kitware RobotXcode generator does not generate schemeThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15441). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15441). Further discussion may take place here.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17031AUTOMOC on generated headers is behavior change in CMake 3.92017-07-10T10:22:02-04:00Brad KingAUTOMOC on generated headers is behavior change in CMake 3.9Since !543 AUTOMOC works on generated headers. This may change behavior for existing projects.
See: https://codereview.qt-project.org/#/c/199038/Since !543 AUTOMOC works on generated headers. This may change behavior for existing projects.
See: https://codereview.qt-project.org/#/c/199038/3.9.0Sebastian HoltermannSebastian Holtermann