CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-09-12T11:48:44-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17045WINDOWS_EXPORT_ALL_SYMBOLS causing link failure on 3.9.0-rc52018-09-12T11:48:44-04:00marsupialWINDOWS_EXPORT_ALL_SYMBOLS causing link failure on 3.9.0-rc5Not sure how to make a lighter test case, but the errors generated do not occur with 3.8.2
```
git clone https://github.com/llvm-mirror/llvm.git
cd llvm/tools
git clone https://github.com/root-project/cling.git
git clone https://g...Not sure how to make a lighter test case, but the errors generated do not occur with 3.8.2
```
git clone https://github.com/llvm-mirror/llvm.git
cd llvm/tools
git clone https://github.com/root-project/cling.git
git clone https://github.com/llvm-mirror/clang.git
cd ../../; mkdir build; cd build;
cmake-3.9.0-rc5 ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host -DPYTHON_EXECUTABLE="G:\Program Files\Python27\python.exe" -DLLVM_LIT_TOOLS_DIR="G:\Program Files (x86)\GnuWin32\bin" -G Ninja
ninja cling
```
Cause the following, which does not happen with with 3.8.2:
The error also occurs when using the Visual Studio generator.
```
exports.def : warning LNK4022: cannot find unique match for symbol '_CT??_R0?AVexception'
exports.def : warning LNK4002: _CT??_R0?AVexception@std@@@824 defined in tools\cling\lib\Interpreter\CMakeFiles\obj.clingInterpreter.dir\Exception.cpp.obj
exports.def : warning LNK4002: _CT??_R0?AVexception@std@@@8??0exception@std@@QEAA@AEBV01@@Z24 defined in f:\binaries\Intermediate\vctools\msvcrt.nativeproj_607447030\objd\amd64\throw_bad_alloc.obj
exports.def : warning LNK4002: _CT??_R0?AVexception@stdext@@@816 defined in lib\Support\CMakeFiles\LLVMSupport.dir\ThreadPool.cpp.obj
exports.def : error LNK2001: unresolved external symbol _CT??_R0?AVexception
```3.9.0Brad KingBrad Kinghttps://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 Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17022FindDoxygen.cmake fails when project() is called in subdirectory2017-07-17T09:45:12-04:00Robert DaileyFindDoxygen.cmake fails when project() is called in subdirectoryInternally, `FindDoxygen.cmake` uses `${PROJECT_BINARY_DIR}` to look for the top-level `CMakeDoxyfile.in` file. This breaks when `doxygen_add_doc()` is invoked in a subdirectory that also calls `project()` beforehand. This modifies the `...Internally, `FindDoxygen.cmake` uses `${PROJECT_BINARY_DIR}` to look for the top-level `CMakeDoxyfile.in` file. This breaks when `doxygen_add_doc()` is invoked in a subdirectory that also calls `project()` beforehand. This modifies the `PROJECT_BINARY_DIR` variable to point to the respective subdirectory in the binary dir tree, which will not have the Doxygen files. Instead, it should use `${CMAKE_BINARY_DIR}`. I tested this and it worked.
I'll provide a PR shortly.3.9.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/17020VS 2015 update changed GenerateDebugInformation back to false/true2017-07-17T09:45:12-04:00Brad KingVS 2015 update changed GenerateDebugInformation back to false/trueFor #15894 commit f086c665da00228cabf465dc1eb7223d40fd6270 changed the `GenerateDebugInformation` setting for the `v140` toolset (and above) from `false/true` to `No/Debug` to match the `$(VCTargetsPath)/1033/link.xml` distributed with V...For #15894 commit f086c665da00228cabf465dc1eb7223d40fd6270 changed the `GenerateDebugInformation` setting for the `v140` toolset (and above) from `false/true` to `No/Debug` to match the `$(VCTargetsPath)/1033/link.xml` distributed with VS 2015 at the time. A later update to VS 2015 has now changed it back to `false/true`, probably due to problems with people's `.vcxproj` files not knowing whether to use `false/true` or `No/Debug`.
VS 2017's `v141` toolset now uses `false/true` as well. I'm not sure whether an older version had `No/Debug`.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/17008CMAKE_CUDA_FLAGS broken on 3.9 rc4 (Visual Studio generator)2017-07-17T09:45:12-04:00Trevor Smith USCMAKE_CUDA_FLAGS broken on 3.9 rc4 (Visual Studio generator)I have been setting nvcc flags through the CMAKE_CUDA_FLAGS variable like so:
`string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_52,code=sm_52 -gencode arch=compute_61,code=sm_61 -use_fast_math -Wno-deprecated-gpu-targets --expt-r...I have been setting nvcc flags through the CMAKE_CUDA_FLAGS variable like so:
`string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_52,code=sm_52 -gencode arch=compute_61,code=sm_61 -use_fast_math -Wno-deprecated-gpu-targets --expt-relaxed-constexpr")`
With 3.9 rc3 and below everything works fine and I see the following under Configuration Properties->CUDA C/C++->Command Line->Additional Options:
`%(AdditionalOptions) -Wno-deprecated-gpu-targets --expt-relaxed-constexpr`
With 3.9 rc4 the build fails because the nvcc flags are malformed. The Additional Options window shows the following:
`-Wno-deprecated-gpu-targets --expt-relaxed-constexpr;-Xcompiler="/EHsc -Zi -Ob0"`3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16997CMake bundles vulnerable copy of Expat - please update to 2.2.12022-02-18T22:09:33-05:00Sebastian PippingCMake bundles vulnerable copy of Expat - please update to 2.2.1[Expat 2.2.1](https://github.com/libexpat/libexpat/blob/master/expat/Changes) contains security fixes. Please update the copy that CMake bundles at [Utilities/cmexpat/lib](https://gitlab.kitware.com/cmake/cmake/tree/master/Utilities/cme...[Expat 2.2.1](https://github.com/libexpat/libexpat/blob/master/expat/Changes) contains security fixes. Please update the copy that CMake bundles at [Utilities/cmexpat/lib](https://gitlab.kitware.com/cmake/cmake/tree/master/Utilities/cmexpat/lib). Thank you!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/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/16962cmake -E server changes default linefeed style of configure_file(...) to LF2018-01-23T09:08:47-05:00Kevin Puetzcmake -E server changes default linefeed style of configure_file(...) to LFWhen configuring my project using Qt creator 4.3 on Windows 7 x64 (which now uses cmake -E server) all configure_file outputs switched from CRLF to LF line endings. However, if they are later regenerated (e.g. ninja RERUN_CMAKE, make cma...When configuring my project using Qt creator 4.3 on Windows 7 x64 (which now uses cmake -E server) all configure_file outputs switched from CRLF to LF line endings. However, if they are later regenerated (e.g. ninja RERUN_CMAKE, make cmake_check_build_system, etc), they switch back to CRLF as before. This causes unnecessary rebuilds and build outputs that differ depending on whether the built is from the IDE's initial setup or an incremental run.
If overridden with NEWLINE_STYLE they can still be forced to either type, but the fact that the default is now inconsistent from run to run seems undesirable.
This misbehavior appears to be caused by the bundled libuv, which is setting the (deprecated) `_fmode = _O_BINARY` global variable
in MSVCRT (https://msdn.microsoft.com/en-us/library/ee2849wt.aspx) and thus changing the default behavior of all subsequent open calls process-wide. This is happening in [uv_fs_init](https://gitlab.kitware.com/cmake/cmake/blob/ed17516b31404dd42eab61c599c84933af485b34/Utilities/cmlibuv/src/win/fs.c#L118), which is called from uv_init and hence from the first call to most any nontrivial libuv function.
I am seeing this behavior from multiple CMake versions, as long as they support -E server (tested 3.7.2, 3.9.0-rc2)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/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/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/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/16913automoc: Too long path issue on Windows platform using cmake 3.8.12020-05-07T02:52:20-04:00Dominique LEDITautomoc: Too long path issue on Windows platform using cmake 3.8.1I upgraded the cmake version we used in our Windows build environment from 3.4.2 to 3.8.1.
We need this upgrade (or at least the upgrade to cmake 3.7.2) because we aim to update Visual Studio to 2017 version, and need for that to have t...I upgraded the cmake version we used in our Windows build environment from 3.4.2 to 3.8.1.
We need this upgrade (or at least the upgrade to cmake 3.7.2) because we aim to update Visual Studio to 2017 version, and need for that to have the corresponding CMake generator.
In Our build environment CMAKE_AUTOMOC is ON
As a result of the cmake version upgrade, I started to have too long path issue, on Windows platform (Windows 7/Windows server 2008 , Visual Studio 2013), with c++ source file generated by moc.
This is a result of the new location for auto-generated files(see AUTOMOC documentation https://cmake.org/cmake/help/v3.8/prop_tgt/AUTOMOC.html). They use to be located in the <CMAKE_CURRENT_BINARY_DIR> and are, with the 3.8 release located in <CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include directory (two more directory levels)
This is hard coded in CMake C++ source code with no way for customization.
So I only have two solutions:
- Re-organize our source code directory tree, trying to shorten directory names, rename the targets using shorter names
- Modify the CMake source code and rebuild CMake 3.8.1 on both Linux and Windows platforms
The first solution is too heavy and we don't have material time to plan such a huge change.
So I quickly patched two C++ cmake source code files to relocate the auto-generated moc files in <CMAKE_BINARY_DIR>/autogen/<target_name>_autogen directory and rebuild cmake 3.8.1 on both Linux and Windows platforms[PatchedCmakeFiles.zip](/uploads/a0c257edf45d93d5483043ff498a3d62/PatchedCmakeFiles.zip).
This is a really annoying problem and it would be very helpful to have an external way to customize the location of the auto-generated file (at least the root directory where to create the <target_name>_autogen directory) using a CMAKE macro for example
Hope this will be integrated quickly.
Thanks
Dominique3.9.0Sebastian HoltermannSebastian Holtermannhttps://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/16896GenExp $<CONFIG> in linked library target sources fails using Unix Makefiles2017-07-11T13:33:51-04:00Sebastian HoltermannGenExp $<CONFIG> in linked library target sources fails using Unix MakefilesThe generator expression `$<CONFIG>` is not evaluated to `CMAKE_BUILD_TYPE` when used in
the sources of a library target that is linked by another target.
Small example project: [cmakeConfigLibBug.tar.gz](/uploads/014dc07c7bfe0c7275cb17...The generator expression `$<CONFIG>` is not evaluated to `CMAKE_BUILD_TYPE` when used in
the sources of a library target that is linked by another target.
Small example project: [cmakeConfigLibBug.tar.gz](/uploads/014dc07c7bfe0c7275cb17ddad81d7d0/cmakeConfigLibBug.tar.gz)
**CMakeLists.txt from the example**
```
cmake_minimum_required ( VERSION 3.7.2 )
# Set build type
set(CMAKE_BUILD_TYPE Debug)
# Library with $<CONFIG> fails
add_library(libA STATIC libA_$<CONFIG>.cpp)
# Executable that links to library
add_executable ( binA main.cpp )
target_link_libraries(binA libA)
```
This is a roadblock for https://gitlab.kitware.com/cmake/cmake/merge_requests/8583.9.0Brad KingBrad Kinghttps://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/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/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 King