CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-10-18T09:30:25-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/19855Allow combining of Windows AppContainer (UWP) executables with native (non-UW...2019-10-18T09:30:25-04:00Mark IngramAllow combining of Windows AppContainer (UWP) executables with native (non-UWP) librariesTo build a UWP application with CMake you need to specify the following flags, `CMAKE_SYSTEM_NAME=WindowsStore CMAKE_SYSTEM_VERSION=10`. When you do this, all libraries within the project are also built as "WindowsStore" libraries (and t...To build a UWP application with CMake you need to specify the following flags, `CMAKE_SYSTEM_NAME=WindowsStore CMAKE_SYSTEM_VERSION=10`. When you do this, all libraries within the project are also built as "WindowsStore" libraries (and therefore target different APIs within Windows). With XamlIslands support in Windows 1903, this is no longer a requirement (that all libraries are also built as "WindowsStore") so the option should be moved from the system variables, into options on `add_executable` and `add_library` (in the same way we have the `add_executable(myapp WIN32)` option right now, we could have a `add_executable(myapp UWP)` option). To preserve backwards compatibility we could set those options by default if `CMAKE_SYSTEM_NAME == WindowsStore` and `CMAKE_SYSTEM_VERSION == 10`?.https://gitlab.kitware.com/cmake/cmake/-/issues/19767Ninja: Compilation of generated Windows Resource .rc file has incorrect depen...2019-09-30T11:45:50-04:00melak47Ninja: Compilation of generated Windows Resource .rc file has incorrect dependenciesI'm using `add_custom_command` with the Ninja generator on Windows to invoke mc.exe on an .mc file, to generate an .rc file, to create a resource DLL.
When making changes to the example.mc file, rebuilding only invokes mc.exe, but depen...I'm using `add_custom_command` with the Ninja generator on Windows to invoke mc.exe on an .mc file, to generate an .rc file, to create a resource DLL.
When making changes to the example.mc file, rebuilding only invokes mc.exe, but dependencies that use the generated example.rc file are not rebuilt until I invoke ninja a second time:
```
> ninja
[0.014s 1/1] Generating example.rc, example.hpp, example_MSG00001.bin
MC: Compiling D:/repro/example.mc
> ninja
[0.027s 1/2] Building RC object CMakeFiles\example.dir\example.rc.res
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
[0.084s 2/2] Linking CXX shared module example.dll
```
I tried the latest releases of CMake 3.11 through 3.15, and this behavior occurred with all of them.
Here are my example [CMakeLists.txt](/uploads/3f8aaf0409d9a489ff675ebd428eb85b/CMakeLists.txt) and [example.mc](/uploads/fe7aa46a6d9a0d0b311cf811c8d4744e/example.mc).
The resulting build.ninja contains this dependency chain:
```
build example.dll: CXX_MODULE_LIBRARY_LINKER__example CMakeFiles\example.dir\example.rc.res
build CMakeFiles\example.dir\example.rc.res: RC_COMPILER__example D$:\repro\build\example.rc || cmake_object_order_depends_target_example
build D$:\repro\build\example.rc: CUSTOM_COMMAND cmake_object_order_depends_target_example
COMMAND = cmd.exe /c
restat = 1
build cmake_object_order_depends_target_example: phony || example.hpp example.rc example_MSG00001.bin
build example.rc example.hpp example_MSG00001.bin: CUSTOM_COMMAND ..\example.mc
COMMAND = cmd.exe /C "cd /D D:\repro\build && "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -b -e hpp -h D:/repro/build -r D:/repro/build D:/repro/example.mc"
DESC = Generating example.rc, example.hpp, example_MSG00001.bin
restat = 1
```
I think that D$:\repro\build\example.rc depending on the actual example.rc file in order-only
is the problem, since that tells ninja not to rebuild D$:\repro\build\example.rc if example.rc changes.
IIRC ninja does not try to figure out that two distinct paths refer to the same file (otherwise,
this would produce an error about multiple build statements producing the same file),
so ninja does not discover that D$:\repro\build\example.rc has changed until the next run.
The `restat = 1` also doesn't help in this case, since it only causes a restat *if the command runs*.
If CMake instead emitted a phony like this:
```
build D$:\repro\build\example.rc: phony example.rc
```
Then targets depending on D$:\repro\build\example.rc would have a real dependency on example.rc,
and would be rebuilt when it changes.
Also, phony build statements don't appear in the build log, unlike the empty CUSTOM_COMMAND which shows up as `cmd /c`.https://gitlab.kitware.com/cmake/cmake/-/issues/19675Windows 10 long path support not taken into account2019-09-04T09:20:59-04:00atsjuWindows 10 long path support not taken into account* Cmake 3.15.2
* ninja 1.8.2
I activated windows 10 long path support following both methods from [here](https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/) but cmake still refuses to build be...* Cmake 3.15.2
* ninja 1.8.2
I activated windows 10 long path support following both methods from [here](https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/) but cmake still refuses to build because too long path.
I know I must shorten the build directory but is there an other way to fix this issue ? And shouldn't cmake be able to make use of the windows long path support ?
```
CMake Warning in CMakeLists.txt:
The object file directory
C:/Program Files (x86)/Jenkins/workspace/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/build_Debug_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/CMakeFiles/outHexFile_Debug_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.elf.dir/
has 182 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
xxxxxx/sources/02_service/xxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.c.obj
cannot be safely placed under this directory. The build may not work
correctly.
-- Generating done
-- Build files have been written to: C:/Program Files (x86)/Jenkins/workspace/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/build_Debug_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```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/19580Windows: Directory removal sometimes fails2021-12-14T06:28:08-05:00Brad KingWindows: Directory removal sometimes failsOn Windows, removing a directory recursively with `cmake -E remove_directory` or `file(REMOVE_RECURSE)` occasionally fails for a few reasons:
* Races with anti-virus tools locking recently created files.
* Races with other tools creatin...On Windows, removing a directory recursively with `cmake -E remove_directory` or `file(REMOVE_RECURSE)` occasionally fails for a few reasons:
* Races with anti-virus tools locking recently created files.
* Races with other tools creating new entries in a directory.
* Races between removing all entries in a directory and removing the directory itself. NTFS deletion is not synchronous.
Our implementation currently uses KWSys [`SystemTools::RemoveADirectory`](https://gitlab.kitware.com/cmake/cmake/blob/v3.15.2/Source/kwsys/SystemTools.cxx#L2755). It could be improved with a more robust removal approach.
Meanwhile some code paths are using [`cmSystemTools::RepeatedRemoveDirectory`](https://gitlab.kitware.com/cmake/cmake/blob/v3.15.2/Source/cmSystemTools.cxx#L2952) to work around this.https://gitlab.kitware.com/cmake/cmake/-/issues/19524VS_NO_DEPLOY has no effect on Windows Phone?2019-07-26T07:29:12-04:00Ben BoeckelVS_NO_DEPLOY has no effect on Windows Phone?In looking into the code to answer a question, I noticed that the docs say:
```rst
Specify that the target should not be marked for deployment to a Windows CE
or Windows Phone device in the generated Visual Studio solution.
```
but the...In looking into the code to answer a question, I noticed that the docs say:
```rst
Specify that the target should not be marked for deployment to a Windows CE
or Windows Phone device in the generated Visual Studio solution.
```
but the code uses the property in a conditional with [`cmGlobalVisualStudio8Generator::TargetSystemSupportsDeployment`](https://gitlab.kitware.com/cmake/cmake/merge_requests/2991/diffs#cec4f8216a5b6115706c255ee293f5adb3084764_292_310) which only allows Windows CE platforms through. How is Windows Phone supposed to use this property? I assume it is just an oversight.
Introduced in !2991.
@brad.king This might need to go into a 3.15.x as either a doc update or bugfix.Wil StarkWil Starkhttps://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/19353CSharp: Can't export or import C# libraries correctly2021-08-26T19:33:09-04:00KonanMCSharp: Can't export or import C# libraries correctlyI stumbled upon this issue when trying to use something along the lines
```
add_library(CsLibrary SHARED CsFile.cs)
install(TARGETS CsLibrary EXPORT CsLibraryTarget)
install(EXPORT CsLibraryTarget DESTINATION ${some_dir} FILE CsLibraryC...I stumbled upon this issue when trying to use something along the lines
```
add_library(CsLibrary SHARED CsFile.cs)
install(TARGETS CsLibrary EXPORT CsLibraryTarget)
install(EXPORT CsLibraryTarget DESTINATION ${some_dir} FILE CsLibraryConfig.cmake)
```
The now generated ${some_dir}/CsLibraryConfig-$<CONFIG>.cmake file is not generated correctly. It is handled like a SHARED C++ library and sets the property IMPORTED_IMPLIB_$<CONFIG> and also appends the nonexistent CsLibrary.lib to the _IMPORT_CHECK_FILES_FOR_CsLibrary list.
C# libraries don't generate any import .lib files so this obviously can't work. I tried to fix this, but then quickly realized that I'm not even sure if it's currently at all possible to generate an imported C# library target.
I know I can use the property VS_DOTNET_REFERENCE_CsLibrary on targets that need to use CsLibrary, but what I would like to do is to generate an imported C# library target which can be consumed by C++ libraries (just like it works when I add the library as part of the build process).
From my point of view some kind of property (heck it could even be IMPORTED_IMPLIB_$<CONFIG>) that points to the CsLibrary.dll would have to be checked by targets that link against C# libraries and it would result in an added VS_DOTNET_REFERENCE_CsLibrary property on that target (or it's getting interpreted by the Visual Studio Generator directly).
I would be willing to contribute to get this fixed, but would like to know which your preferred solution is.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/19171create *.lib implib for windows dll with mingw-w642019-05-03T18:23:11-04:00NeroBurnercreate *.lib implib for windows dll with mingw-w64I'd like to instruct CMake to instruct mingw-w64 to create a `*.lib` for the shared `*.dll` C library
I'm trying to cross compile a lapack.dll (and the accompanying lapack.lib) from the lapack project
https://github.com/Reference-LAPACK...I'd like to instruct CMake to instruct mingw-w64 to create a `*.lib` for the shared `*.dll` C library
I'm trying to cross compile a lapack.dll (and the accompanying lapack.lib) from the lapack project
https://github.com/Reference-LAPACK/lapack
The resulting shared lib should be usable by MSVC (so I don't need to setup a fortran compiler on Windows). MSVC needs a `*.lib` implib to link to the dll
I found the flag `-Wl,--out-implib,libshared_dll.lib` from the following link
http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
I don't want to set custom `CMAKE_Fortran_COMPILE_FLAGS` if I can avoid it. Also the created `lapack-config.cmake` file should link to the `*.lib` file instead of the now generated `*.dll.a` file.https://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/19142FindBoost: Does not detect gcc arch-model on windows102019-04-08T10:32:31-04:00Ghost UserFindBoost: Does not detect gcc arch-model on windows10I compile Boost library with this options:
```./b2 toolset=gcc address-model=x64 variant=release link=static runtime-link=static threading=multi install -j8```
the output of boost library format is:
```
libboost_sytem-mgw81-mt-s-x64...I compile Boost library with this options:
```./b2 toolset=gcc address-model=x64 variant=release link=static runtime-link=static threading=multi install -j8```
the output of boost library format is:
```
libboost_sytem-mgw81-mt-s-x64-1_69.a
```
and the cmake to find boost option is:
```
set(Boost_THREADAPI pthread)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_LIBS ON)
set( Boost_ARCHITECTURE -x64)
```
If I don't set Boost_ARCHITECHTURE flag and auto-compute :
cmake search library debug output is:
```
Searching for SYSTEM_LIBRARY_RELEASE: libboost_system-mgw81-mt-s-1_69;libboost_system-mgw81-mt-s;libboost_system-mgw81-mt-s;libboost_system-mt-s-1_69;libboost_system-mt-s;libboost_system-mt-s;libboost_system-mt;libboost_system
Searching for SYSTEM_LIBRARY_DEBUG: libboost_system-mgw81-mt-sd-1_69;libboost_system-mgw81-mt-sd;libboost_system-mgw81-mt-sd;libboost_system-mt-sd-1_69;libboost_system-mt-sd;libboost_system-mt-sd;libboost_system-mt;libboost_system
```
then cmake reports `Could not find following static Boost libraries
boost_system`https://gitlab.kitware.com/cmake/cmake/-/issues/19140cmake-gui ignores all command line arguments except -S and -B2021-01-04T16:08:59-05:00Bogdan Bcmake-gui ignores all command line arguments except -S and -Bcmake-gui (in latest released version 3.14.1) ignores all command line arguments.
Only specifying the source and build folders works, everything else is ignored.
Not even cmake-gui --help works. See this screenshot:
![image](/uploads/3...cmake-gui (in latest released version 3.14.1) ignores all command line arguments.
Only specifying the source and build folders works, everything else is ignored.
Not even cmake-gui --help works. See this screenshot:
![image](/uploads/3371889e77114b85ac2f50a3f2478230/image.png)
The really bad part is that it ignores all variables defined on the command line, with -D\<var>=\<value>, which breaks any command lines configured with such arguments.https://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 Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19102"cmake -E tar xf" symlink on Windows with Unicode UTF-8 system locale2020-03-03T17:14:13-05:00Alexej Harm"cmake -E tar xf" symlink on Windows with Unicode UTF-8 system localeThe `cmake -E tar xf` functionality changed between 3.13.4 and 3.14.0 in regards to `tar` archives containing symlinks.
CMake 3.14.0
```
> cmake -E tar xf harfbuzz-harfbuzz-2.3.1.tar.gz
CMake Error: Problem with archive_write_header(): ...The `cmake -E tar xf` functionality changed between 3.13.4 and 3.14.0 in regards to `tar` archives containing symlinks.
CMake 3.14.0
```
> cmake -E tar xf harfbuzz-harfbuzz-2.3.1.tar.gz
CMake Error: Problem with archive_write_header(): Can't create ''
CMake Error: Current file: harfbuzz-2.3.1/README
CMake Error: Problem extracting tar: harfbuzz-harfbuzz-2.3.1.tar.gz
```
CMake 3.13.4
```
> cmake -E tar xf harfbuzz-harfbuzz-2.3.1.tar.gz
cmake -E tar: warning: skipping symbolic link "harfbuzz-2.3.1/README" -> "README.md".
```
Tested on Windows 10 1809 with this: https://github.com/harfbuzz/harfbuzz/archive/2.3.1.tar.gzhttps://gitlab.kitware.com/cmake/cmake/-/issues/19077Authenticode support in CMake2022-05-20T11:17:23-04:00Cristian AdamAuthenticode support in CMakeAt the moment CMake users on Windows have a problem when CMake releases are being published. The software is not digitally signed using "authenticode".
Microsoft Edge browser, and others, initially block unseen, unsigned new software.
...At the moment CMake users on Windows have a problem when CMake releases are being published. The software is not digitally signed using "authenticode".
Microsoft Edge browser, and others, initially block unseen, unsigned new software.
This is a common practice on Windows to sign the binaries. It ensures that the software comes from that specific vendor and that it hasn't been tampered with it. It also provides the date at which it has been signed.
This is more or less like the websites using SSL. cmake.org is using "Let's Encrypt" certificates, but kitware.com is using certificates from DigiCert, which unlinke "Let's Encrypt" it offers Authenticode certificates.
https://stackoverflow.com/questions/84847/how-do-i-create-a-self-signed-certificate-for-code-signing-on-windows offers the insights how to use self signed certificates.
This would be needed for developing this feature in CMake, not every developer has it's own authenticode.
CMake would need to have Authenticode support for:
* install command. Every binary and shared library needs to be signed
* CPack, for package signing.
One just needs to call `signtool` with the path to the certificate, which can be skipped if it's part of the computer's keystore (/a), and the timestamp url (/t):
```
signtool sign /v /f MyCertificate.pfx /t http://timestamp.url MyExecutable.exe
signtool sign /v /a /t http://timestamp.url MyExecutable.exe
```
One could have something like:
* CMAKE_AUTHENTICODE_CERTIFICATE_PATH
* CMAKE_AUTHENTICODE_CERTIFICATE_AUTO
* CMAKE_AUTHENTICODE_TIMESTAMP_URL
It would be just a `add_custom_command` call. But it helps all the Windows CMake users, which use CMake to develop software professionally.https://gitlab.kitware.com/cmake/cmake/-/issues/19049find_program returns wrong paths when searching on a Windows share2019-03-28T12:24:07-04:00Paul Bodenbennerfind_program returns wrong paths when searching on a Windows shareStarting with CMake 3.13.0 find_program returns wrong paths when searching on a Windows share. This did not happen on earlier versions, tested e.g. 3.12.4. When a network path is passed to find_program (e.g.: //host/path) the executable ...Starting with CMake 3.13.0 find_program returns wrong paths when searching on a Windows share. This did not happen on earlier versions, tested e.g. 3.12.4. When a network path is passed to find_program (e.g.: //host/path) the executable is found but the returned path has only one slash at the beginning (e.g.: /host/path).
* 3.12.4 --> works
* 3.13.0 --> does not work
* 3.14.0-rc4 --> does not work
The attached minimal example can be used to demonstrate the problem by using following command:
`cmake.exe -DPROGRAM_NAME=test -DPROGRAM_PATH=//host/path .`
The returned path is printed using the message command.
[CMakeLists.txt](/uploads/b0ca951d22d2571b7c7e97aea6c88b5f/CMakeLists.txt)3.14.1Brad KingBrad King