CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-02-01T12:34:07-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/22845Genex: Clarify TARGET_RUNTIME_DLLS behavior on imported targets2022-02-01T12:34:07-05:00Robert MaynardGenex: Clarify TARGET_RUNTIME_DLLS behavior on imported targetsTARGET_RUNTIME_DLLS computes to an empty string in add_custom_command:
```cmake
cmake_minimum_required(VERSION 3.21)
project(test)
find_package(CUDAToolkit REQUIRED)
add_executable(exe test.cpp)
target_link_libraries(exe PRIVATE CUDA:...TARGET_RUNTIME_DLLS computes to an empty string in add_custom_command:
```cmake
cmake_minimum_required(VERSION 3.21)
project(test)
find_package(CUDAToolkit REQUIRED)
add_executable(exe test.cpp)
target_link_libraries(exe PRIVATE CUDA::cudart CUDA::cublas)
add_custom_command(TARGET exe POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_RUNTIME_DLLS:exe> $<TARGET_FILE_DIR:exe>
COMMAND_EXPAND_LISTS
)
```
MSVC 20.19 output:
```
Build started...
1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------
1>Checking Build System
2>------ Build started: Project: exe, Configuration: Debug x64 ------
2>Building Custom Rule C:/Work/temp/RuntimeDlls/CMakeLists.txt
2>test.cpp
2>exe.vcxproj -> C:\Work\temp\RuntimeDlls_build\Debug\exe.exe
2>EXEC : CMake error : cmake version 3.21.4
2>Usage: C:\Program Files\CMake\bin\cmake.exe -E <command> [arguments...]
2>Available commands:
2> capabilities - Report capabilities built into cmake in JSON format
2> cat <files>... - concat the files and print them to the standard output
2> chdir dir cmd [args...] - run command in a given directory
2> compare_files [--ignore-eol] file1 file2
2> - check if file1 is same as file2
2> copy <file>... destination - copy files to destination (either file or directory)
2> copy_directory <dir>... destination - copy content of <dir>... directories to 'destination' directory
2> copy_if_different <file>... destination - copy files if it has changed
2> echo [<string>...] - displays arguments as text
```3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22846[Feature Request] Add interactive debugging support to CMake2021-11-03T10:20:56-04:00Eric Fedosejevs[Feature Request] Add interactive debugging support to CMakeAdding interactive debugging support to CMake would be a huge quality of life improvement when debugging large CMake code bases. It would also facilitate better CMake build system integration with IDEs.
Some debugging tools that might b...Adding interactive debugging support to CMake would be a huge quality of life improvement when debugging large CMake code bases. It would also facilitate better CMake build system integration with IDEs.
Some debugging tools that might be worth including:
- breakpoints
- watch variables
- step into/over
- print variable value
...
For ease of use and user familiarity I would recommend using the commands from GDB as a template.https://gitlab.kitware.com/cmake/cmake/-/issues/22847CMAKE_GNUtoMS does not work with VS 20222022-02-01T12:33:15-05:00Stefano SinigardiCMAKE_GNUtoMS does not work with VS 2022No .lib is generated from .dll.a with the same toolchain that works when enabling previous VS versions (2019, 2017, ...)
Tested with CMake 3.21.4, which should support VS 2022 RCNo .lib is generated from .dll.a with the same toolchain that works when enabling previous VS versions (2019, 2017, ...)
Tested with CMake 3.21.4, which should support VS 2022 RC3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22848Compiler/TI response file regression with Make generator2023-05-14T16:19:05-04:00Stefano SinigardiCompiler/TI response file regression with Make generatorafter having updated to CMake 3.21 we had to add
```
set(CMAKE_C_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 0)
```
to our `SitaraToolchain.cmake` toolchain file in order to not have problems at linkin...after having updated to CMake 3.21 we had to add
```
set(CMAKE_C_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 0)
```
to our `SitaraToolchain.cmake` toolchain file in order to not have problems at linking phase. Otherwise, linking was failing with a message of "path too long" from the `objects1.rsp` file (curious, since response file should be done exactly to avoid this problem...)
see https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6159#note_1045209
note: we use make generator, not ninjahttps://gitlab.kitware.com/cmake/cmake/-/issues/22849VS: Model target framework in CMAKE_GENERATOR_PLATFORM2021-11-09T12:55:34-05:00Brad KingVS: Model target framework in CMAKE_GENERATOR_PLATFORMSee the Visual Studio documentation on [Framework targeting](https://web.archive.org/web/20210715112558/https://docs.microsoft.com/en-us/visualstudio/ide/visual-studio-multi-targeting-overview?view=vs-2019#change-the-target-framework). ...See the Visual Studio documentation on [Framework targeting](https://web.archive.org/web/20210715112558/https://docs.microsoft.com/en-us/visualstudio/ide/visual-studio-multi-targeting-overview?view=vs-2019#change-the-target-framework). Generated project files need to specify a target framework somehow.
CMake has some support for this already. See the [CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION](https://cmake.org/cmake/help/v3.21/variable/CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION.html) variable and [DOTNET_TARGET_FRAMEWORK](https://cmake.org/cmake/help/v3.21/prop_tgt/DOTNET_TARGET_FRAMEWORK.html) target property to control the `TargetFrameworkVersion`. However, that only works for project targets, and not for `try_compile` or similar. Issue #22835 raises a case where we need to generate an explicit `TargetFrameworkVersion` even in the tiny project CMake creates during compiler identification.
In principle, the target framework is just as fundamental to generation as the target platform. See the VS documentation on [MSBuild target framework and target platform](https://web.archive.org/web/20211103162707/https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019) and [Target frameworks in SDK-style projects](https://web.archive.org/web/20211023025702/https://docs.microsoft.com/en-us/dotnet/standard/frameworks). Therefore we should support specifying the target framework as part of [CMAKE_GENERATOR_PLATFORM](https://cmake.org/cmake/help/v3.21/variable/CMAKE_GENERATOR_PLATFORM.html), and also select a default explicitly when needed (e.g. VS 2022 for #22835).
In [CMAKE_GENERATOR_TOOLSET](https://cmake.org/cmake/help/v3.21/variable/CMAKE_GENERATOR_TOOLSET.html#visual-studio-toolset-selection) we already support comma-separated fields with additional settings. We could do the same for `CMAKE_GENERATOR_PLATFORM`, and then add a `framework=` field for the target framework. We may need to offer controls for:
* `TargetFrameworkVersion` / `TargetFrameworkIdentifier` / `TargetFrameworkTargetsVersion`
* `TargetFramework`
depending on the style of the project.
This capability may become important to help users update their target framework version after [.NET Framework 4.5.2, 4.6, 4.6.1 reach End of Support](https://web.archive.org/web/20211031104237/https://devblogs.microsoft.com/dotnet/net-framework-4-5-2-4-6-4-6-1-will-reach-end-of-support-on-april-26-2022/).https://gitlab.kitware.com/cmake/cmake/-/issues/22850target_precompile_headers: Support for BEFORE and AFTER2021-11-05T12:20:17-04:00BrassSuzumetarget_precompile_headers: Support for BEFORE and AFTERAfter looking up on of the generated pch files in my project I noticed that target_precompile_headers append the list of precompiled headers of linked libraries to the back of target's pch file. This leads to my problem where I have two ...After looking up on of the generated pch files in my project I noticed that target_precompile_headers append the list of precompiled headers of linked libraries to the back of target's pch file. This leads to my problem where I have two libraries (A and B, B links against A) that have their own set of precompiled headers. In case of B, some precompiled headers are dependent on headers defined in A's precompiled headers. Because precompiled headers of A are appended to the back of B's pch, B fails to build. So far, I can see two workarounds for the problem:
- #include required headers in B's header files
- add required headers to target_precompile_headers in B (place them before the header that requires them)
I quickly glimpsed over the CMake src and extending support for BEFORE and AFTER seems pretty straightforward. I believe some additional care should be taken when handling REUSE_FROM together with those flags (probably REUSE_FROM should be mutually exclusive with AFTER/BEFORE).
I am not sure if it is up to the discussion here, but maybe it would be good to consider making target_precompile_headers default behaviour to PREPEND instead of APPEND precompiled headers of linked libraries. Personally, I would find it more intuitive but probably it is just me and there are many reasons why the current approach is better.https://gitlab.kitware.com/cmake/cmake/-/issues/22851pip installed CMake doesn't find pip installed pybind112021-11-03T17:02:00-04:00Nick Thompsonpip installed CMake doesn't find pip installed pybind11To reproduce:
```
$ python3.9 -m venv .
$ . bin/activate
$ python3 -m pip install cmake
Collecting cmake
Using cached cmake-3.21.4-py2.py3-none-macosx_10_9_universal2.macosx_10_9_x86_64.macosx_11_0_arm64.macosx_11_0_universal2.whl (72...To reproduce:
```
$ python3.9 -m venv .
$ . bin/activate
$ python3 -m pip install cmake
Collecting cmake
Using cached cmake-3.21.4-py2.py3-none-macosx_10_9_universal2.macosx_10_9_x86_64.macosx_11_0_arm64.macosx_11_0_universal2.whl (72.4 MB)
Installing collected packages: cmake
Successfully installed cmake-3.21.4
$ python3 -m pip install pybind11
Collecting pybind11
Using cached pybind11-2.8.1-py2.py3-none-any.whl (208 kB)
Installing collected packages: pybind11
Successfully installed pybind11-2.8.1
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.21.1)
project(Reproduce)
find_package(pybind11 REQUIRED)
$ mkdir build && cd build
$ cmake ../
CMake Error at CMakeLists.txt:5 (find_package):
By not providing "Findpybind11.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "pybind11",
but CMake did not find one.
Could not find a package configuration file provided by "pybind11" with any
of the following names:
pybind11Config.cmake
pybind11-config.cmake
Add the installation prefix of "pybind11" to CMAKE_PREFIX_PATH or set
"pybind11_DIR" to a directory containing one of the above files. If
"pybind11" provides a separate development package or SDK, be sure it has
been installed.
-- Configuring incomplete, errors occurred!
```https://gitlab.kitware.com/cmake/cmake/-/issues/22852add_custom_target with BYPRODUCTS works correctly either with ninja or make, ...2021-11-04T12:53:44-04:00Sergey Naumovadd_custom_target with BYPRODUCTS works correctly either with ninja or make, but not bothProblematic case:
```
add_custom_target(filename ALL
COMMAND some_command dep > filename
BYPRODUCTS filename
DEPENDS dep)
```
If BYPRODUCTS is present, then everything is OK with make, but in ninja there is a warning and er...Problematic case:
```
add_custom_target(filename ALL
COMMAND some_command dep > filename
BYPRODUCTS filename
DEPENDS dep)
```
If BYPRODUCTS is present, then everything is OK with make, but in ninja there is a warning and error:
```
ninja: warning: phony target ... names itself as an input; ignoring [-w phonycycle=warn]
ninja: error: build.ninja:6476: multiple rules generate ... [-w dupbuild=err]
```
If BYPRODUCTS is commented out, then everything is OK with ninja, but 'make clean' does not clean \<filename\>.
Used cmake version is 3.21.3
How it is supposed to use add_custom_target to avoid this issue?https://gitlab.kitware.com/cmake/cmake/-/issues/22853target_include_directories() documentation doesn't explicitly say what relati...2022-02-03T09:17:50-05:00Cristian Morales Vegatarget_include_directories() documentation doesn't explicitly say what relative paths are relative totarget_include_directories()'s documentation says:
> Specified include directories may be absolute paths or relative paths.
But it doesn't explicitly say what relative paths are relative to.
Later it says.
> Relative paths are allowed ...target_include_directories()'s documentation says:
> Specified include directories may be absolute paths or relative paths.
But it doesn't explicitly say what relative paths are relative to.
Later it says.
> Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix.
Which, when combined, may make you think relative paths are allowed **only** within the INSTALL_INTERFACE.
FWIW Craig's Professional CMake says
> Relative paths will be automatically converted to absolute paths where needed (with one exception
discussed below), with paths being treated as relative to the current source directory.
Which is the behaviour I have always seen.https://gitlab.kitware.com/cmake/cmake/-/issues/22854`if( ... MATCHES ...)` should first preprocess the path contains special char...2021-11-07T21:02:02-05:00Jack·Boos·Yu`if( ... MATCHES ...)` should first preprocess the path contains special charactersHi, see you again.
We received an issue about the `MATCHES` expression in https://github.com/microsoft/vcpkg/issues/21154.
The user installed vcpkg in the path containing the special characters `+` used in regular expressions and got th...Hi, see you again.
We received an issue about the `MATCHES` expression in https://github.com/microsoft/vcpkg/issues/21154.
The user installed vcpkg in the path containing the special characters `+` used in regular expressions and got the error message:
```
CMake Error at cmake/OpenCVUtils.cmake:90 (if):
if given arguments:
"C:/C++/vcpkg/buildtrees/opencv2/x64-windows-dbg" "MATCHES" "^C:/C++/vcpkg/buildtrees/opencv2/src/2.4.13.7-64eb3208d2.clean" "OR" "C:/C++/vcpkg/buildtrees/opencv2/x64-windows-dbg" "MATCHES" "^C:/C++/vcpkg/buildtrees/opencv2/x64-windows-dbg"
Regular expression
"^C:/C++/vcpkg/buildtrees/opencv2/src/2.4.13.7-64eb3208d2.clean" cannot
compile
Call Stack (most recent call first):
CMakeLists.txt:351 (ocv_include_directories)
```
The origin code is:
```cmake
if("${__abs_dir}" MATCHES "^${OpenCV_SOURCE_DIR}" OR "${__abs_dir}" MATCHES "^${OpenCV_BINARY_DIR}")
```
Since the system allows this directory to be generated, and the left and right directories of the expression are enclosed in double quotes `"`, I think this should be a cmake bug.
We can use the following code to reproduce this issue:
```cmake
set(__abs_dir "C:/C++/vcpkg/buildtrees/opencv2/x64-windows-dbg")
set(OpenCV_SOURCE_DIR "^C:/C++/vcpkg/buildtrees/opencv2/src/2.4.13.7-64eb3208d2.clean")
set(OpenCV_BINARY_DIR "^C:/C++/vcpkg/buildtrees/opencv2/x64-windows-dbg")
if("${__abs_dir}" MATCHES "^${OpenCV_SOURCE_DIR}" OR "${__abs_dir}" MATCHES "^${OpenCV_BINARY_DIR}")
endif()
```
In my opinion, if the left and right content of `MATCHES` contains these special characters, it must be preprocessed to add `\` in front of them.
Any ideas?
Thanks.https://gitlab.kitware.com/cmake/cmake/-/issues/22855add_custom_target dependencies wrong with CMAKE_CROSS_CONFIGS=all2021-11-05T10:09:32-04:00Jörg Bornemannadd_custom_target dependencies wrong with CMAKE_CROSS_CONFIGS=allConsider the attached project [custom_target_deps.tar.gz](/uploads/4f1a72e7c27d682ed1400923c8664fe2/custom_target_deps.tar.gz):
```cmake
cmake_minimum_required(VERSION 3.20)
project(custom_command_deps)
add_executable(generator generato...Consider the attached project [custom_target_deps.tar.gz](/uploads/4f1a72e7c27d682ed1400923c8664fe2/custom_target_deps.tar.gz):
```cmake
cmake_minimum_required(VERSION 3.20)
project(custom_command_deps)
add_executable(generator generator.cpp)
add_executable(XY::generator ALIAS generator)
add_custom_command(
OUTPUT generated1.cpp
COMMAND "$<TARGET_FILE:generator>" generated1.cpp 1
VERBATIM)
add_custom_target(foo1 DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated1.cpp")
add_custom_command(
OUTPUT generated2.cpp
COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated2.cpp 2
VERBATIM)
add_custom_target(foo2 DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated2.cpp")
add_custom_command(
OUTPUT generated3.cpp
COMMAND "NARF=zort" "$<COMMAND_CONFIG:$<TARGET_FILE:generator>>" generated3.cpp 3
VERBATIM)
add_custom_target(foo3 DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated3.cpp")
add_custom_command(
OUTPUT generated4.cpp
COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated4.cpp 4
DEPENDS generator
VERBATIM)
add_custom_target(foo4 DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated4.cpp")
add_custom_command(
OUTPUT generated5.cpp
COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated5.cpp 5
DEPENDS XY::generator
VERBATIM)
add_custom_target(foo5 DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/generated5.cpp")
```
We have a code generator and five custom commands that each create a .cpp file by calling that generator.
Each custom command's output is depended on by a custom target.
We're building this project with
```
cmake -G"Ninja Multi-Config" -DCMAKE_CONFIGURATION_TYPES=Release\;Debug -DCMAKE_CROSS_CONFIGS=all -DCMAKE_DEFAULT_CONFIGS=all <source-dir>
```
All `fooX:Release` targets depend on `Release/generator`. This is expected.
The dependencies to the generator differ in the `fooX:Debug` targets, which is unexpected:
`foo1:Debug` is connected to the command that creates generated1.cpp\
Command: `COMMAND "$<TARGET_FILE:generator>" generated1.cpp 1`\
Dependency: `foo1:Debug -> Release/generator`
This dependency is expected.
`foo2:Debug` is connected to the command that creates generated2.cpp\
Command: `COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated2.cpp 2`\
Dependency: `foo2:Debug -> Debug/generator`
Here, the `TARGET_FILE` generator expression is not the first argument after `COMMAND`.
But that should not make a difference, since the documentation states:
> If either OUTPUT or BYPRODUCTS names a path that is common to more than one configuration (e.g. it does not use any generator expressions), all arguments are evaluated in the command config by default.
Wrapping `TARGET_FILE` in `$<COMMAND_CONFIG>` as done for `foo3` fixes the dependency, so we have a work-around.
Another observation:\
When adding an explicit `DEPENDS`, it makes a difference whether we depend on `generator` or an alias target of `generator`. This is demonstrated by the targets `foo4` and `foo5`:
Command: `COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated4.cpp 4`\
Depends: `DEPENDS generator`\
Dependency: `foo4:Debug -> Debug/generator`
Command: `COMMAND "NARF=zort" "$<TARGET_FILE:generator>" generated5.cpp 5`\
Depends: `DEPENDS XY::generator`\
Dependency: `foo5:Debug -> Release/generator`
For reference, this is with CMake 3.21.1.3.22.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22856Cannot set per-target flags for the Windows rc compiler2021-11-04T12:02:52-04:00Jörg BornemannCannot set per-target flags for the Windows rc compilerThe Windows resource compiler (rc.exe / windres.exe) is represented as language "RC" in CMake.
But it's not possible to set flags per target for this tool. Or at least not the way I've tried.
Consider this example:
```
cmake_minimum_req...The Windows resource compiler (rc.exe / windres.exe) is represented as language "RC" in CMake.
But it's not possible to set flags per target for this tool. Or at least not the way I've tried.
Consider this example:
```
cmake_minimum_required(VERSION 3.21)
project(rc_compiler_specific_flags_per_target)
file(WRITE "${CMAKE_CURRENT_SOURCE_DIR}/main.cpp" "int main() {}")
file(WRITE "${CMAKE_CURRENT_SOURCE_DIR}/myexe.rc" "/* empty resource */")
add_executable(myexe main.cpp myexe.rc)
target_compile_options(myexe PRIVATE $<$<COMPILE_LANGUAGE:RC>:/invalid-switch>)
```
This example compiles without error despite the attempt to pass an invalid switch to rc.
This was discussed before here: https://discourse.cmake.org/t/is-compile-language-rc-supported-for-resource-files/3142https://gitlab.kitware.com/cmake/cmake/-/issues/22857Help: configure_file() FILE_PERMISSIONS values aren't documented2021-11-04T12:46:27-04:00Raul Tambreraul@tambre.eeHelp: configure_file() FILE_PERMISSIONS values aren't documented`configure_file()`'s documentation doesn't mention what options are valid. They're mentioned in `file(CHMOD)` and `install()` documentation. The latter's includes:
> Permissions that do not make sense on certain platforms are ignored on...`configure_file()`'s documentation doesn't mention what options are valid. They're mentioned in `file(CHMOD)` and `install()` documentation. The latter's includes:
> Permissions that do not make sense on certain platforms are ignored on those platforms
Which `file(CHMOD)` doesn't mention.
`configure_file()` should have the documentation for valid options and the documentation for all of these should be unified.https://gitlab.kitware.com/cmake/cmake/-/issues/22858target_link_libraries: Optionally require only target names2022-01-21T15:07:57-05:00Brad Kingtarget_link_libraries: Optionally require only target namesSome projects may wish to thoroughly make all link dependencies available as targets, either imported or built by the project.
We could add some kind of optional check to fail generation with a CMake Error when a non-target is encountered.Some projects may wish to thoroughly make all link dependencies available as targets, either imported or built by the project.
We could add some kind of optional check to fail generation with a CMake Error when a non-target is encountered.3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22859Can we rely on _CMAKE_FEATURE_DETECTION_TARGET_TYPE?2021-11-05T09:39:02-04:00Petr HosekCan we rely on _CMAKE_FEATURE_DETECTION_TARGET_TYPE?This came up in https://reviews.llvm.org/D112126 where we could use `_CMAKE_FEATURE_DETECTION_TARGET_TYPE` to solve our problem but the name suggests that this is an internal variable. Can we use this variable in our own CMake files or i...This came up in https://reviews.llvm.org/D112126 where we could use `_CMAKE_FEATURE_DETECTION_TARGET_TYPE` to solve our problem but the name suggests that this is an internal variable. Can we use this variable in our own CMake files or is there a risk that it'll get removed/replaced in the future?https://gitlab.kitware.com/cmake/cmake/-/issues/22860CUDA: Support CUDA_ARCHITECTURES all and all-major on Clang and older NVCC2022-02-02T08:23:22-05:00Raul Tambreraul@tambre.eeCUDA: Support CUDA_ARCHITECTURES all and all-major on Clang and older NVCCWe need only detect the CUDA toolkit version and then maintain lists for each one's support versions. Shouldn't be too difficult, though spelunking for the older releases might be difficult.We need only detect the CUDA toolkit version and then maintain lists for each one's support versions. Shouldn't be too difficult, though spelunking for the older releases might be difficult.3.23.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22861CPACK_INSTALL_CMAKE_PROJECTS documentation is confusing2021-11-05T09:57:10-04:00Cristian Morales VegaCPACK_INSTALL_CMAKE_PROJECTS documentation is confusingThe documentation of CPACK_INSTALL_CMAKE_PROJECTS says
```
List of four values that specify what project to install. The four values are: Build directory, Project Name, Project Component, Directory. If omitted, CPack will build an instal...The documentation of CPACK_INSTALL_CMAKE_PROJECTS says
```
List of four values that specify what project to install. The four values are: Build directory, Project Name, Project Component, Directory. If omitted, CPack will build an installer that installs everything.
```
which seems to indicate a single project is allowed.https://gitlab.kitware.com/cmake/cmake/-/issues/22862When generating -G "Visual Studio 14 2015" for target that 2019 with compile...2021-11-05T11:26:34-04:00Yonggang LuoWhen generating -G "Visual Studio 14 2015" for target that 2019 with compiler 2015 installed, the building procedure will fail, can the cmake detecting msvc 2015 compiler installed with msvc 2019 properly?```
[main] Configuring folder: pedeps
[driver] Removing e:/CI-Cor-Ready/15/im/pedeps/build/CMakeCache.txt
[driver] Removing e:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" -...```
[main] Configuring folder: pedeps
[driver] Removing e:/CI-Cor-Ready/15/im/pedeps/build/CMakeCache.txt
[driver] Removing e:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -He:/CI-Cor-Ready/15/im/pedeps -Be:/CI-Cor-Ready/15/im/pedeps/build -G "Visual Studio 14 2015" -A win32
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Selecting Windows SDK version to target Windows 10.0.19043.
[cmake] CMake Error at CMakeLists.txt:2 (project):
[cmake] Failed to run MSBuild command:
[cmake]
[cmake] MSBuild.exe
[cmake]
[cmake] to get the value of VCTargetsPath:
[cmake]
[cmake] Microsoft(R) 生成引擎版本 4.8.4084.0
[cmake] [Microsoft .NET Framework 版本 4.0.30319.42000]
[cmake] 版权所有 (C) Microsoft Corporation。保留所有权利。
[cmake]
[cmake] 生成启动时间为 2021/11/5 23:19:59。
[cmake] 节点 1 上的项目“E:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles\3.20.2\VCTargetsPath.vcxproj”(默认目标)。
[cmake] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\win32\Microsoft.Cpp.win32.Targets(518,5): error MSB8008: Specified platform toolset (v140) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [E:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles\3.20.2\VCTargetsPath.vcxproj]
[cmake] 已完成生成项目“E:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles\3.20.2\VCTargetsPath.vcxproj”(默认目标)的操作 - 失败。
[cmake]
[cmake] 生成失败。
[cmake]
[cmake] “E:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles\3.20.2\VCTargetsPath.vcxproj”(默认目标) (1) ->
[cmake] (PlatformPrepareForBuild 目标) ->
[cmake] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\win32\Microsoft.Cpp.win32.Targets(518,5): error MSB8008: Specified platform toolset (v140) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [E:\CI-Cor-Ready\15\im\pedeps\build\CMakeFiles\3.20.2\VCTargetsPath.vcxproj]
[cmake]
[cmake] 0 个警告
[cmake] 1 个错误
[cmake]
[cmake] 已用时间 00:00:00.54
[cmake]
[cmake]
[cmake] Exit code: 1
[cmake]
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "E:/CI-Cor-Ready/15/im/pedeps/build/CMakeFiles/CMakeOutput.log".
```https://gitlab.kitware.com/cmake/cmake/-/issues/22863CMAKE_SYSTEM_PREFIX_PATH: Do not add CMAKE_INSTALL_PREFIX2022-03-28T09:45:31-04:00Brad KingCMAKE_SYSTEM_PREFIX_PATH: Do not add CMAKE_INSTALL_PREFIXThere is code in [Modules/Platform/UnixPaths.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.4/Modules/Platform/UnixPaths.cmake#L35-46) that adds `CMAKE_INSTALL_PREFIX` to the `CMAKE_SYSTEM_PREFIX_PATH`. This was added by com...There is code in [Modules/Platform/UnixPaths.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.4/Modules/Platform/UnixPaths.cmake#L35-46) that adds `CMAKE_INSTALL_PREFIX` to the `CMAKE_SYSTEM_PREFIX_PATH`. This was added by commit
507896e03b77842513799b7413afb667fffe9f35 and commit 2a782880645ad366e724fa0d1657ab233bfe6676 to support a workflow in which a user interactively builds a chain of dependent projects and installs them all into the same prefix.
We should consider removing this behavior with a policy:
* The motivating use case for the feature can be more explicitly handled by setting `CMAKE_PREFIX_PATH` in one's environment or project cache. That solution will help with #20363 too.
* The implementation does not work in call cases. See https://gitlab.kitware.com/cmake/cmake/-/issues/21242#note_859517.
* There are use cases where it doesn't make sense. [CMAKE_FIND_NO_INSTALL_PREFIX](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_NO_INSTALL_PREFIX.html) was added by commit fe057ab3cd2469af5440307f1bf2a4f69d686db3 to support them, but threading that value through everywhere it is needed may be tricky.https://gitlab.kitware.com/cmake/cmake/-/issues/22864CMP0077 policy issue2021-11-09T13:44:53-05:00Paula&AleCMP0077 policy issueIs this expected? Am I doing something wrong runnning the tests?
![image](/uploads/e713dda3c01dfeaaf517eb2fe81c3209/image.png)
![image](/uploads/2963bc9deb68babb1a5fcb3cf04766c2/image.png)Is this expected? Am I doing something wrong runnning the tests?
![image](/uploads/e713dda3c01dfeaaf517eb2fe81c3209/image.png)
![image](/uploads/2963bc9deb68babb1a5fcb3cf04766c2/image.png)