CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2020-05-01T08:32:39-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/20659CPackDeb: Debian packages built on Windows fail to install2020-05-01T08:32:39-04:00Jan DeinhardCPackDeb: Debian packages built on Windows fail to installI am using CPackDeb to build Debian packages on Windows. When running `dpkg -i my-package_0.0.1_all.deb` I get the following error message:
```
dpkg-deb: error: archive has invalid format version: format version followed by junk
dpkg: e...I am using CPackDeb to build Debian packages on Windows. When running `dpkg -i my-package_0.0.1_all.deb` I get the following error message:
```
dpkg-deb: error: archive has invalid format version: format version followed by junk
dpkg: error processing archive my-package_0.0.1_all.deb (--install):
subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
my-package_0.0.1_all.deb
```
Using the same configuration I can build valid Debian packages on Linux.
After reading the source code of `dpkg` and CMake I think I found the cause. There seems to be a problem in the `debian-binary` created on Windows:
```
void DebGenerator::generateDebianBinaryFile() const
{
// debian-binary file
const std::string dbfilename = WorkDir + "/debian-binary";
cmGeneratedFileStream out(dbfilename);
out << "2.0";
out << std::endl; // required for valid debian package
}
```
On Windows the `std::endl` ist translated to `\r\n` because the file is opened in text mode. `dpkg` does not like Windows line endings.
To confirm I changed the method as follows:
```
void DebGenerator::generateDebianBinaryFile() const
{
// debian-binary file
const std::string dbfilename = WorkDir + "/debian-binary";
cmGeneratedFileStream out;
out.Open(dbfilename, false, true);
out.put('2');
out.put('.');
out.put('0');
out.put('\n');
}
```
Here the file is opened in binary mode and voila it works ...
... until the control file is parsed where again the final `std::endl` from `DebGenerator::generateControlFile()` causes `dpkg` to complain.3.18.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20585Ninja: On Windows, select the compiler occurring first in PATH2020-04-23T09:31:06-04:00Duncan OgilvieNinja: On Windows, select the compiler occurring first in PATHHello,
In `Modules/CMakeDetermineCXXCompiler.cmake` the variable `CMAKE_CXX_COMPILER_LIST` is set, which is then used by `_cmake_find_compiler` (https://gitlab.kitware.com/cmake/cmake/-/blob/v3.17.1/Modules/CMakeDetermineCompiler.cmake)...Hello,
In `Modules/CMakeDetermineCXXCompiler.cmake` the variable `CMAKE_CXX_COMPILER_LIST` is set, which is then used by `_cmake_find_compiler` (https://gitlab.kitware.com/cmake/cmake/-/blob/v3.17.1/Modules/CMakeDetermineCompiler.cmake) to find the compiler to use. From the comments I can see there is supposed to be some kind of 'preferred' order, but it's not entirely clear how that works.
On my machine I have `gcc` and `ld` in the system PATH (because of an unrelated Haskell Platform installation), but when running from a Visual Studio command prompt (which puts `cl.exe` and `link.exe` first in the PATH) CMake still prefers `cc`, `c++` and `ld` and this behavior is very surprising (I imagine even more so for newer users who might have a bunch of compilers installed when learning).
I just patched the following line in my CMake installation to get the search order I want, but I was wondering why CMake doesn't simply use the PATH to determine the user's preference.
Line I patched:
```
set(CMAKE_CXX_COMPILER_LIST CC ${_CMAKE_TOOLCHAIN_PREFIX}c++ ${_CMAKE_TOOLCHAIN_PREFIX}g++ aCC cl bcc xlC clang++)
```
I know (now) you can specify `-DCMAKE_CXX_COMPILER=cl.exe` or set the `CC` and `CXX` variables, but I think using the PATH as the search order would make a lot more sense since it would have fewer surprises and initialization scripts always put the desired compiler in the PATH first.
I cannot find any documentation mentioning this as the 'official' search order (although admittedly I didn't look very hard) so it wouldn't break anything users couldn't depend on already.
Please let me know what you think,
Duncan3.18.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20529llvm-rc: Compiling RC files no longer finds adjacent data files2020-04-07T08:00:50-04:00delthasllvm-rc: Compiling RC files no longer finds adjacent data filesWhen compiling Windows RC files on the Windows-Clang platform, with llvm-rc, the folder of the resource is not added to the resource compiler include path.
This is a fairly serious bug for projects using Windows RC files that are compil...When compiling Windows RC files on the Windows-Clang platform, with llvm-rc, the folder of the resource is not added to the resource compiler include path.
This is a fairly serious bug for projects using Windows RC files that are compiled with the Windows-Clang platform and in particular `llvm-rc`, caused by !4219.
When compiling a Windows resource file with `llvm-rc`, CMake used to simply invoke `llvm-rc` on that resource file in its original source folder.
Since that patch, CMake instead invokes its own command-line tool `cmake_llvm_rc` that does two steps:
- preprocess that resource file into an intermediary preprocessed resource file, somewhere in the CMakeFiles build folder
- invoke `llvm-rc` on that new file.
The cause of the bug is that `llvm-rc` now processes the resource file in the new folder, rather than in its original source folder.
Now consider a project where a resource file `resource.rc` references a resource `resource.dat` in its current directory, like so (this is not an edge-case, it is a typically way to reference and include a resource file into an executable):
```4 RCDATA "resource.dat"```
To look up the reference file in order to read it, `llvm-rc` [mimicks the original behaviour of the Windows Resource Compiler and looks up paths in the following order](https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-rc/ResourceFileWriter.cpp#L1511):
- if the file path is absolute and exists, try to use that; otherwise:
- search in the current working directory
- **search in the directory of the input resource file**
- search in all of the include directories specified on the command line
The path used to be matched by the third case *(search in the directory of the input resource file)*, because that direcotry was indeed the directory that contained the resource file and in our example the resource as well.
But now, the directory of the input resource file has changed and is now inside the CMakeFiles folder which does not contain the resource. So none of the paths contain that resource and the file cannot be looked up, **resulting in a build failure**.
To me the simplest way to fix this would be to add to the include directories specified on the command line of `llvm-rc`, the path of the folder containing the original resource file. Specifically perhaps modify [that line in Platform/Windows-Clang.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Platform/Windows-Clang.cmake#L145) to add a `/I <SOURCE_DIR>` where `SOURCE_DIR` is the folder containing `SOURCE`.3.17.1https://gitlab.kitware.com/cmake/cmake/-/issues/20514CPack broken for Windows/NSIS for CMake 3.17.*: "ReserveFile /plugin" results...2020-04-01T10:43:31-04:00Jason ErbCPack broken for Windows/NSIS for CMake 3.17.*: "ReserveFile /plugin" results in script errorCPack is broken for Windows/NSIS for CMake 3.17+.
The error message in NSISOutput.log when attempting to build the "package" target using NSIS or NSIS64 generators:
```
Usage: ReserveFile [/nonfatal] [/r] [/x filespec [...]] file [file....CPack is broken for Windows/NSIS for CMake 3.17+.
The error message in NSISOutput.log when attempting to build the "package" target using NSIS or NSIS64 generators:
```
Usage: ReserveFile [/nonfatal] [/r] [/x filespec [...]] file [file...]
Error in script ".../_CPack_Packages/win64/NSIS/project.nsi" on line 633 -- aborting creation process
```
Line 633 in project.nsi is:
```
ReserveFile /plugin 'UserInfo.dll'
```
That line was added during [this change](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4171).
The problem affects 3.17.\*; 3.16 versions works correctly.
This issue was observed on Windows 10 x64.3.17.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20320cmake -E tar fails to create archive with "archive_write_header: Can't record...2020-02-11T09:12:04-05:00Ivan Onyshchenkocmake -E tar fails to create archive with "archive_write_header: Can't record entry in tar file without pathname" on Windows 10The issue is present, when `Language Settings -> Administrative language settings -> Change system locale... -> Beta: Use Unicode UTF-8 for worldwide language support` is enabled. When option is disabled it works as expected.
Please, f...The issue is present, when `Language Settings -> Administrative language settings -> Change system locale... -> Beta: Use Unicode UTF-8 for worldwide language support` is enabled. When option is disabled it works as expected.
Please, find below steps to reproduce, cmake and system info.
```
c:\work\test_cmake_tar>cmake -E tar c out.tar -- file.txt
CMake Error: archive_write_header: Can't record entry in tar file without pathname
CMake Error: Problem creating tar: out.tar
c:\work\test_cmake_tar>type file.txt
Hi to builtin tar archiver
c:\work\test_cmake_tar>cmake --version
cmake version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
Excerpt from systeminfo output:
```
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.18363 N/A Build 18363
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
System Type: x64-based PC
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn,
```
This issue may be related to [#20050](https://gitlab.kitware.com/cmake/cmake/issues/20050)3.16.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20300MinGW: MSVC standard library usage requirements2020-02-04T13:28:22-05:00Daan De MeyerMinGW: MSVC standard library usage requirementsI opened https://gitlab.kitware.com/cmake/cmake/issues/19496 a while ago which was fixed by defaulting to C++14 on Windows when using the Clang GNU frontend. Now I'm noticing the same problem when using MinGW on Windows (errors in MSVC s...I opened https://gitlab.kitware.com/cmake/cmake/issues/19496 a while ago which was fixed by defaulting to C++14 on Windows when using the Clang GNU frontend. Now I'm noticing the same problem when using MinGW on Windows (errors in MSVC standard library headers because `-std=c++11` is used when setting `CXX_STANDARD 11`, `CXX_STANDARD_REQUIRED ON`, `CXX_EXTENSIONS OFF` and `target_compile_features(${TARGET} PUBLIC cxx_std_11)`). Can the same fix be used here?https://gitlab.kitware.com/cmake/cmake/-/issues/20274Ninja: metadata clean-on-regenerate broken on Windows2021-03-11T05:29:50-05:00Brad KingNinja: metadata clean-on-regenerate broken on WindowsThe change in !3316 for #15830 does not work on Windows with Ninja 1.10 when running `ninja` re-runs CMake internally. The outer ninja holds the log files open so the `ninja -t *` tools fail with:
```
ninja: error: failed recompaction:...The change in !3316 for #15830 does not work on Windows with Ninja 1.10 when running `ninja` re-runs CMake internally. The outer ninja holds the log files open so the `ninja -t *` tools fail with:
```
ninja: error: failed recompaction: Permission denied
```3.19.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20162Windows-GNU.cmake needs minor update to support Visual Studio 20192020-01-10T13:20:09-05:00Kelly (KT) ThompsonWindows-GNU.cmake needs minor update to support Visual Studio 2019I needed this small diff to use `Windows-GNU.cmake` with _Visual Studio 16 2019_:
```diff
# Query the VS Installer tool for locations of VS 2017 and above.
set(_vs_installer_paths "")
+ foreach(vs RANGE 16 15 -1) # change th...I needed this small diff to use `Windows-GNU.cmake` with _Visual Studio 16 2019_:
```diff
# Query the VS Installer tool for locations of VS 2017 and above.
set(_vs_installer_paths "")
+ foreach(vs RANGE 16 15 -1) # change the first number to the largest supported version
- foreach(vs RANGE 15 15 -1) # change the first number to the largest supported version
cmake_host_system_information(RESULT _vs_dir QUERY VS_${vs}_DIR)
if(_vs_dir)
list(APPEND _vs_installer_paths "${_vs_dir}/VC/Auxiliary/Build")
```
* Is there a larger VS2019 effort that can absorb this small change?
* This diff is against `cmake-3.16.2`3.16.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20077Missing import library for ARM64 Windows 102019-12-11T10:31:27-05:00Tatsuro ShibamuraMissing import library for ARM64 Windows 10I found that a link error occurred when building for Windows 10 on ARM64 (not UWP, Like Surface Pro X).
It seems that only a few import libraries are set in the standard module of cmake even for ARM64 other than UWP.
https://gitlab.kitw...I found that a link error occurred when building for Windows 10 on ARM64 (not UWP, Like Surface Pro X).
It seems that only a few import libraries are set in the standard module of cmake even for ARM64 other than UWP.
https://gitlab.kitware.com/cmake/cmake/blob/v3.16.0/Modules/Platform/Windows-MSVC.cmake#L221https://gitlab.kitware.com/cmake/cmake/-/issues/20021Clang/LLVM-MinGW: Implicit include directories detected with newlines2019-12-16T10:40:23-05:00Cristian AdamClang/LLVM-MinGW: Implicit include directories detected with newlinesThe [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm...The [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm-mingw/include/c++/v1
;C:/llvm-mingw/lib/clang/9.0.0/include
;C:/llvm-mingw/include
")
```
Which causes problems in identifying if an include path is part of the implicit include directories list.3.15.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20019MinGW: Drop find_library support for plain .dll files2021-11-30T10:28:08-05:00Brad KingMinGW: Drop find_library support for plain .dll filesThe `CMAKE_FIND_LIBRARY_SUFFIXES` variable used by `find_library` to consider file suffixes for linkable libraries contains `.dll` when using MinGW tools. At least at one time it was possible to link directly to a `.dll` instead of usin...The `CMAKE_FIND_LIBRARY_SUFFIXES` variable used by `find_library` to consider file suffixes for linkable libraries contains `.dll` when using MinGW tools. At least at one time it was possible to link directly to a `.dll` instead of using an import library. However, in practice packages tend to always provide the `.dll.a` import library, and it is wrong to find a MSVC-ABI `.dll` too. Maybe we should drop plain `.dll` from the default list of extensions on MinGW.3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19954CUDA: CMake 3.15 uses `--options-file` when linking static cuda library with ...2020-02-25T08:54:51-05:00Mika FischerCUDA: CMake 3.15 uses `--options-file` when linking static cuda library with `link.exe`3.14 works fine...
```
[587/624] Linking CUDA static library foo.lib
FAILED: foo.lib
cmd.exe /C "cd . && link.exe /lib /nologo /machine:x64 /out:foo.lib --options-file CMakeFiles\foo.rsp && cd ."
LINK : warning LNK4044: Nicht er...3.14 works fine...
```
[587/624] Linking CUDA static library foo.lib
FAILED: foo.lib
cmd.exe /C "cd . && link.exe /lib /nologo /machine:x64 /out:foo.lib --options-file CMakeFiles\foo.rsp && cd ."
LINK : warning LNK4044: Nicht erkannte Option /-options-file; wird ignoriert.
```https://gitlab.kitware.com/cmake/cmake/-/issues/19583Flang: MSVC_RUNTIME_LIBRARY support on Windows2019-08-19T14:54:47-04:00Brad KingFlang: MSVC_RUNTIME_LIBRARY support on WindowsIn !3211 we overlooked updating flags for Flang on WindowsIn !3211 we overlooked updating flags for Flang on Windows3.15.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19496Clang GNU: MSVC standard library usage requirements2020-02-02T07:20:42-05:00Daan De MeyerClang GNU: MSVC standard library usage requirementsWith the new Windows Clang GNU frontend variant support, a lot of projects are failing to compile because they specify C++11 as the CMake standard but depend on the MSVC standard library headers which use C++14. I've been fixing these pr...With the new Windows Clang GNU frontend variant support, a lot of projects are failing to compile because they specify C++11 as the CMake standard but depend on the MSVC standard library headers which use C++14. I've been fixing these projects by checking if the Clang GNU frontend is used on Windows and increasing the C++ version if this is the case but ideally, CMake would automatically add the correct usage requirements to each target depending on which standard library is used.
So for example, a project that uses the MSVC stdlib would have C++14 usage requirements added to all its C++ targets by CMake.3.15.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19382FindMATLAB: matlab_add_mex command is broken since CMake v3.14 with MSVC 15.42020-01-14T08:56:04-05:00Florian WoltersFindMATLAB: matlab_add_mex command is broken since CMake v3.14 with MSVC 15.4It seems that the `matlab_add_mex` command is broken (at least for MSVC 15.4 using Windows 7) since version 3.14.0 of CMake.
# Short, Self Contained, Correct Example (SSCCE)
`CMakeLists.txt`:
cmake_minimum_required(VERSION 3.14.5)...It seems that the `matlab_add_mex` command is broken (at least for MSVC 15.4 using Windows 7) since version 3.14.0 of CMake.
# Short, Self Contained, Correct Example (SSCCE)
`CMakeLists.txt`:
cmake_minimum_required(VERSION 3.14.5)
include(FindMatlab)
project(cpp-example-matlab_mex LANGUAGES CXX)
matlab_get_version_from_release_name("R2018b" Matlab_VERSION)
find_package(Matlab ${Matlab_VERSION})
matlab_add_mex(
NAME example_mex
SRC "${CMAKE_CURRENT_SOURCE_DIR}/mex_function.cpp"
R2018a
)
`mex_function.cpp`:
// MATLAB
#include <mex.h>
void mexFunction(int nlhs, mxArray* plhs[], int nrhs, mxArray const* prhs[]) {
// NOOP
}
`build.cmd`:
@echo off
cls
cmake ^
-G "Visual Studio 15 2017 Win64" ^
-T v141 ^
-S . ^
-B _build ^
-DCMAKE_CXX_COMPILER:FILEPATH=cl ^
-DCMAKE_SYSTEM_VERSION:STRING=10.0.16299.0 ^
-DMatlab_ROOT_DIR:PATH="C:/Program Files/Matlab/R2018b" ^
-DMATLAB_FIND_DEBUG:BOOL=OFF
cmake --build _build --config Debug
Running `build.cmd` gives the following linker errors ("unresolved symbol"):
LINK : error LNK2001: Nicht aufgelöstes externes Symbol "mexCreateMexFunction". [C:\dev\_build\example_mex.vcxproj]
LINK : error LNK2001: Nicht aufgelöstes externes Symbol "mexDestroyMexFunction". [C:\dev\_build\example_mex.vcxproj]
LINK : error LNK2001: Nicht aufgelöstes externes Symbol "mexFunctionAdapter". [C:\dev\_build\example_mex.vcxproj]
LINK : error LNK2001: Nicht aufgelästes externes Symbol "mexfilerequiredapiversion". [C:\dev\_build\example_mex.vcxproj]
C:/dev/_build/Debug/example_mex.lib : fatal error LNK1120: 4 nicht aufgelöste Externe [C:\dev\_build\example_mex.vcxproj]
# Workaround
Commenting out lines 1028 and 1033 of `FindMatlab.cmake` as follows:
set(_link_flags "${_link_flags} /EXPORT:mexFunction")
if(NOT ${Matlab_VERSION_STRING} VERSION_LESS "9.1") # For 9.1 (R2016b) and newer, export version
# TODO(2019-06-14 by wolters): Linker error with Microsoft Visual Studio 2017.
#set(_link_flags "${_link_flags} /EXPORT:mexfilerequiredapiversion")
endif()
if(Matlab_HAS_CPP_API)
# TODO(2019-06-14 by wolters): Linker error with Microsoft Visual Studio 2017.
#set(_link_flags "${_link_flags} /EXPORT:mexCreateMexFunction /EXPORT:mexDestroyMexFunction /EXPORT:mexFunctionAdapter")
#TODO: Is this necessary?
endif()
# Questions
1. Why are these three functions exported at all?
2. Is there a workaround that does not require to hack `FindMatlab.cmake`?https://gitlab.kitware.com/cmake/cmake/-/issues/19298swift linker flags are propagated improperly for mixed language projects on W...2019-06-04T08:33:18-04:00Saleem Abdulrasoolswift linker flags are propagated improperly for mixed language projects on WindowsTrying to port libdispatch to the new Swift support, I noticed that the following causes problems on Windows:
```cmake
cmake_minimum_required(VERSION 3.14.20190523)
project(P LANGUAGES C CXX Swift)
```
The C/C++ checks for the linker a...Trying to port libdispatch to the new Swift support, I noticed that the following causes problems on Windows:
```cmake
cmake_minimum_required(VERSION 3.14.20190523)
project(P LANGUAGES C CXX Swift)
```
The C/C++ checks for the linker add `/MACHINE:x64` to the linker flags which propagate to the Swift check and cause issues.https://gitlab.kitware.com/cmake/cmake/-/issues/19203Improve LLVM for Visual Studio compiler detection2019-05-03T11:43:55-04:00Zufu LiuImprove LLVM for Visual Studio compiler detectionI maintained a non-official repository contains LLVM MSBuild script for Visual Studio 2010 to 2019 at https://github.com/zufuliu/llvm-utils
The toolset names are LLVM_v90, LLVM_v100, LLVM_v110, LLVM_v110_xp, LLVM_v120, LLVM_v120_xp, etc ...I maintained a non-official repository contains LLVM MSBuild script for Visual Studio 2010 to 2019 at https://github.com/zufuliu/llvm-utils
The toolset names are LLVM_v90, LLVM_v100, LLVM_v110, LLVM_v110_xp, LLVM_v120, LLVM_v120_xp, etc (set repository readme). All toolset name suffix are in lower case (`_v[0-9]+(_xp)?`).
Currently when running cmake like `cmake -Bbuild -H. -A x64 -T LLVM_v142`, the `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER` not detected correctly compared to running `cmake -Bbuild -H. -A x64 -T llvm`. MSVC cl.exe is detected in former case, while clang-cl.exe in later case.
See the bug report at
https://github.com/zufuliu/llvm-utils/issues/2
Change (in file Modules/CMakeDetermineCompilerId.cmake)
```cmake
if(CMAKE_VS_PLATFORM_TOOLSET MATCHES "^[Ll][Ll][Vv][Mm]$")
set(id_cl_var "ClangClExecutable")
```
to
```cmake
if(CMAKE_VS_PLATFORM_TOOLSET MATCHES "^[Ll][Ll][Vv][Mm](_v[0-9]+(_xp)?)?$")
set(id_cl_var "ClangClExecutable")
```
could fix this.
Related bug: https://gitlab.kitware.com/cmake/cmake/issues/19174https://gitlab.kitware.com/cmake/cmake/-/issues/19160cmake-gui: default taskbar overlay icon on Windows2019-04-12T07:29:24-04:00mistersandman9495-mistersandman@users.noreply.gitlab.kitware.comcmake-gui: default taskbar overlay icon on WindowsSince CMake 3.14.0, a default overlay icon appears in the taskbar on Windows, when using `cmake-gui.exe`:
![cmake_icon_overlay](/uploads/669f105f37caf5575e59b96ae60efa5c/cmake_icon_overlay.png)
An attempt to set the overlay icon is mad...Since CMake 3.14.0, a default overlay icon appears in the taskbar on Windows, when using `cmake-gui.exe`:
![cmake_icon_overlay](/uploads/669f105f37caf5575e59b96ae60efa5c/cmake_icon_overlay.png)
An attempt to set the overlay icon is made [here](https://gitlab.kitware.com/cmake/cmake/blob/a550e2d6e48798d342a5ba7436013c6aa6ce5151/Source/QtDialog/CMakeSetupDialog.cxx#L306), although the resource `:/loading.png` is never defined and therefore not found, which makes Windows fall back to this default overlay icon. Also, I didn't find any code that would reset the overlay icon after loading, so I'm not sure what the intention was when introducing it.
Removing the line linked above fixes the issue.3.14.2https://gitlab.kitware.com/cmake/cmake/-/issues/19147cmake-gui: no theme on Windows since CMake 3.142019-04-09T08:01:05-04:00Maartencmake-gui: no theme on Windows since CMake 3.14CMake 3.14 does not use the default Windows theme anymore. Screenshots from the ZIP packages (3.13.4 and latest development distribution), installer version has the same problem.
<img src="/uploads/30b991d28c1edccbe6a470878345168b/3.13....CMake 3.14 does not use the default Windows theme anymore. Screenshots from the ZIP packages (3.13.4 and latest development distribution), installer version has the same problem.
<img src="/uploads/30b991d28c1edccbe6a470878345168b/3.13.png" width="300">
<img src="/uploads/b7e56782f9b9a12a74c6978f368e49db/3.14.png" width="300">3.14.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19108MSVC: Add abstraction for runtime library selection2023-09-07T07:12:57-04:00Brad KingMSVC: Add abstraction for runtime library selectionCMake currently [hard codes](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.1/Modules/Platform/Windows-MSVC.cmake#L361-364) defaults for `/MD` and `/MDd`. There is a [FAQ entry](https://gitlab.kitware.com/cmake/community/wikis/FAQ#ho...CMake currently [hard codes](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.1/Modules/Platform/Windows-MSVC.cmake#L361-364) defaults for `/MD` and `/MDd`. There is a [FAQ entry](https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-build-my-msvc-application-with-a-static-runtime) on how to change them but the process is not simple and requires knowing CMake's existing default. That means we cannot even change our default from `/MD` to `-MD` without a policy.
Instead we should introduce a first-class abstraction for choosing the MSVC runtime library via an enumeration. We've long hesitated to do this because the idea of "runtime library selection" touches on related concepts on several platforms. We can avoid that scope creep by simply defining an abstraction that applies *only when targeting the MSVC ABI on Windows* (regardless of what compiler is being used).
3.15.0Brad KingBrad King