CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-11-08T19:36:57-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/24080Allow disabling STARTMENU in NSIS CPack generator2022-11-08T19:36:57-05:00Mojca MiklavecAllow disabling STARTMENU in NSIS CPack generatorI would like to remove the "Choose Start Menu Folder" screen in the NSIS installer, but I don't find a suitable option for that.
My package only contains libraries and headers, no executable files, so it doesn't make any sense for the u...I would like to remove the "Choose Start Menu Folder" screen in the NSIS installer, but I don't find a suitable option for that.
My package only contains libraries and headers, no executable files, so it doesn't make any sense for the user to choose what and where to install to the start menu.https://gitlab.kitware.com/cmake/cmake/-/issues/24089Ninja: UTF-8 filenames don't work anymore on windows with ninja 1.102022-11-01T11:06:49-04:00Aaron SiegelNinja: UTF-8 filenames don't work anymore on windows with ninja 1.10We have a file named "Kodak® T-Max 100.tif" that gets copied with a custom build command like this
```
set(SOURCE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/Kodak® T-Max 100.tif")
get_filename_component(SOURCE_FILENAME "${SOURCE_FILE}" NAME)
s...We have a file named "Kodak® T-Max 100.tif" that gets copied with a custom build command like this
```
set(SOURCE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/Kodak® T-Max 100.tif")
get_filename_component(SOURCE_FILENAME "${SOURCE_FILE}" NAME)
set(OUTPUT_FILE "${CMAKE_CURRENT_BINARY_DIR}/${SOURCE_FILENAME}")
add_custom_command(OUTPUT "${OUTPUT_FILE}"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different "${SOURCE_FILE}" "${OUTPUT_FILE}"
MAIN_DEPENDENCY "${SOURCE_FILE}"
VERBATIM
)
target_sources(${TARGET_NAME} PRIVATE "${OUTPUT_FILE}")
source_group("Generated Files" FILES "${OUTPUT_FILE}")
```
On macOS this works fine for all versions of CMake, on Windows this works fine for CMake 3.21.7, but with CMake 3.24.2 it doesn't work anymore on windows using Ninja or MSVC (I assume it broke before that just not sure when)3.23.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24068Ninja: Lots of showInclude logs due to encoding msvc_deps_prefix to utf-82022-10-31T09:44:16-04:00kangjianbinNinja: Lots of showInclude logs due to encoding msvc_deps_prefix to utf-8This original issue was reported in https://github.com/ninja-build/ninja/issues/613
Looks like the regression was introduced in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5860.
> CMake can detect the prefix correctly, and...This original issue was reported in https://github.com/ninja-build/ninja/issues/613
Looks like the regression was introduced in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5860.
> CMake can detect the prefix correctly, and stores it in its variable 'CMAKE_CL_SHOWINCLUDES_PREFIX' (or CMAKE_CXX_CL_SHOWINCLUDES_PREFIX). Note that this prefix is not utf-8 encoding. For example, in my locale it is encoded in 'GB18030'.
>
> However, when creating rules.ninja, cmake converts this prefix to utf-8 and saves the converted data to msvc_deps_prefix.
>
> During build, msvc_deps_prefix (utf-8 encoding) cannot match MSVC's output (gb18030 enconding, et al), so Ninja reports lots of include files.
I switched to cmake-3.20, which doesn't convert the prefix to utf-8, and everything works well.3.25.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22355CMake 3.21.0-rc unable to establish a SSL connection on Windows2022-10-28T18:01:00-04:00Peter WaleckiCMake 3.21.0-rc unable to establish a SSL connection on WindowsCMake 3.21.0-rc is unable to open SSH connections to download dependencies when configuring Open3D on Windows 10. Downgrading to 3.19.0 resolves the issue.
cmake produces the following error:
```
Performing download step (download, ver...CMake 3.21.0-rc is unable to open SSH connections to download dependencies when configuring Open3D on Windows 10. Downgrading to 3.19.0 resolves the issue.
cmake produces the following error:
```
Performing download step (download, verify and extract) for 'ext_turbojpeg'
-- verifying file...
file='D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz'
-- SHA256 hash of
D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz
does not match expected value
expected: '005aee2fcdca252cee42271f7f90574dda64ca6505d9f8b86ae61abc2b426371'
actual: 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
-- File already exists but hash mismatch. Removing...
-- Downloading...
dst='D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz'
timeout='none'
inactivity timeout='none'
-- Using src='https://github.com/libjpeg-turbo/libjpeg-turbo/archive/refs/tags/2.0.6.tar.gz'
CMake Error at ext_turbojpeg-stamp/download-ext_turbojpeg.cmake:170 (message):
Each download failed!
CUSTOMBUILD : error : downloading 'https://github.com/libjpeg-turbo/libjpeg-turbo/archive/refs/tags/2.0.6.tar.gz' faile
d [D:\Documents\Brown\Open3D\build\ext_turbojpeg.vcxproj]
status_code: 35
status_string: "SSL connect error"
log:
--- LOG BEGIN ---
timeout on name lookup is not supported
Trying 140.82.112.4:443...
Connected to github.com (140.82.112.4) port 443 (#0)
schannel: disabled automatic use of client certificate
schannel: ALPN, offering h2
schannel: ALPN, offering http/1.1
schannel: initial InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
received (e.g. handshake failed). More detail may be available in the
Windows System event log.
Closing connection 0
--- LOG END ---
```
Steps to reproduce.
1. clone Open3D from https://github.com/intel-isl/Open3D.git (commit hash 09aa226f993180bf2ab7e8884e740db6e9c219bd)
2. Open cmd with Admin priviledges
3. cd Open3D
4. mkdir build
5. cd build
6. cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX="../install" -DBUILD_PYTHON_MODULE=OFF ..3.21.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16282"cmake.exe -E __create_def" is crashing when adding /GL flag to CMAKE_CXX_FLA...2022-10-28T17:42:18-04:00Tadeu Manoel"cmake.exe -E __create_def" is crashing when adding /GL flag to CMAKE_CXX_FLAGS, for MSVC 2015When running this command in the pre-link step (from inside MSVC, when building a project), cmake is crashing, and it gives an error like this:
```
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128...When running this command in the pre-link step (from inside MSVC, when building a project), cmake is crashing, and it gives an error like this:
```
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: The command "setlocal
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: cd D:\build14
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: D:\bin\cmake.exe -E __create_def D:/build14/source/.../RelWithDebInfo//exportall.def D:/build14/source/.../RelWithDebInfo//objects.txt
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmErrorLevel
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: exit /b %1
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :cmDone
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(128,5): error MSB3073: :VCEnd" exited with code -1073741819.
```https://gitlab.kitware.com/cmake/cmake/-/issues/17191CMake 3.9 Generates build.ninja failed on Non-Engish Windows2022-10-26T18:10:13-04:00Force.Charlie-ICMake 3.9 Generates build.ninja failed on Non-Engish WindowsStarting with CMake 3.9, cmake cannot generates `build.ninja` on Non-Engish Windows. When we use `chcp 65001` or change current console CodePage, cmake can generates `build.ninja`.
cmake 3.8.2 is success.
CMake log:
```
CMake Error at...Starting with CMake 3.9, cmake cannot generates `build.ninja` on Non-Engish Windows. When we use `chcp 65001` or change current console CodePage, cmake can generates `build.ninja`.
cmake 3.8.2 is success.
CMake log:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.9/Modules/CMakeTestCXXCompiler.cmake:44 (message):
The C++ compiler "C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX64/x86/cl.exe" is
not able to compile a simple test program.
It fails with the following output:
Change Dir: D:/git/vcpkg/buildtrees/gflags/x86-windows-rel/CMakeFiles/CMakeTmp
Run Build
Command:"D:/git/vcpkg/downloads/tools/ninja/ninja-1.7.2/ninja.exe"
"cmTC_81c7a"
ninja: error: build.ninja:30: loading 'rules.ninja':
系统找不到指定的文件。
include rules.ninja
^ near here
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:94 (project)
```
This error info is `The system cannot find
the file specified`
Your can use chcp change console codepage to non-Engish Windows (cp936) test `cmake -GNinja`.
```powershell
Function ProcessExec {
param(
[string]$FilePath,
[string]$Arguments,
[string]$WorkingDirectory
)
$ProcessInfo = New-Object System.Diagnostics.ProcessStartInfo
$ProcessInfo.FileName = $FilePath
Write-Host "$FilePath $Arguments $PWD"
if ($WorkingDirectory.Length -eq 0) {
$ProcessInfo.WorkingDirectory = $PWD
}
else {
$ProcessInfo.WorkingDirectory = $WorkingDirectory
}
$ProcessInfo.Arguments = $Arguments
$ProcessInfo.UseShellExecute = $false ## use createprocess not shellexecute
$Process = New-Object System.Diagnostics.Process
$Process.StartInfo = $ProcessInfo
if ($Process.Start() -eq $false) {
return -1
}
$Process.WaitForExit()
return $Process.ExitCode
}
Function ClangNinjaGenerator{
param(
[String]$ClangExe,
[String]$BuildDir
)
$env:CC=$ClangExe
$env:CXX=$ClangExe
Write-Host "Build llvm, Use: CC=$env:CC CXX=$env:CXX"
Set-Workdir $BuildDir
$Arguments=Get-ClangArgument
$oe=[Console]::OutputEncoding
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 ### Ninja need UTF8
$exitcode = ProcessExec -FilePath "cmake.exe" -Arguments $Arguments
if ($exitcode -ne 0) {
Write-Error "CMake exit: $exitcode"
return 1
}
[Console]::OutputEncoding=$oe
$PN = & Parallel
$exitcode = ProcessExec -FilePath "ninja.exe" -Arguments "all -j $PN"
return $exitcode
}
```
This problem can be reproduced
https://github.com/Microsoft/vcpkg/issues/16603.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22899MSVC PDB generation strategies2022-10-26T09:51:34-04:00Ben BoeckelMSVC PDB generation strategiesIn !6721, I tried to improve CI by using flags that work with `sccache`. However, [CMake uses an incompatible strategy for PDB files](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6721#note_1082123) in that it uses a per-librar...In !6721, I tried to improve CI by using flags that work with `sccache`. However, [CMake uses an incompatible strategy for PDB files](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6721#note_1082123) in that it uses a per-library `.pdb` file rather than per-TU files which just doesn't work with any (simple) caching mechanism. I propose a per-target property which can be used to select the PDB strategy for the target (names subject to bikeshedding):
```cmake
set(CMAKE_PDB_STRATEGY PER_TU) # defaults to PER_TARGET for compat
set(CMAKE_PDB_LEVEL NONE) # or DEFAULT or EDIT_AND_CONTINUE
# also CMAKE_PDB_LEVEL_<CONFIG> with sensible defaults per config
```
AFAICT, `EDIT_AND_CONTINUE` is not compatible with `PER_TU` since it requires `/ZI` which is incompatible with `sccache` (fine for CI which doesn't need `EDIT_AND_CONTINUE` anyways).
Things to consider:
- See CMP0091 for how to move the existing flags out of the global settings into these target properties
- Behaviors with MSVC-emulating compilers (`clang-cl`)?
- Gathering per-TU `.pdb` files into a final target-wide `.pdb` file (related: how do `OBJECT` libraries do this?).
- Could/should `PDB_LEVEL` be shared at some level with other compilers (`-g`, `-ggdb`, `-Og`, etc.)?
- Can `PDB_STRATEGY` also encompass `-gsplit-dwarf`?
- What to do if the strategy doesn't support the level? Downgrade the strategy, level, or error?
See also:
- #10189 (`/Zi` vs `/ZI` for Debug builds)
- #19549 (using `/Z` at all for Release builds)
- #20256 (separate debug info, generally)
- #16874 (NatVis support)
- #20812 (default flag selection for MSVC)
Cc: @brad.king @craig.scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/17904Use external/system includes feature from Visual Studio 15.62022-10-21T11:16:27-04:00RichardUse external/system includes feature from Visual Studio 15.6In response of gcc/clang's command switch "-isystem" VS2017 v15.6 gained a new switch "/external:I" for supporting external/system include paths to prevent warning from third-party headers.
CMake should make use of it.
A closer descript...In response of gcc/clang's command switch "-isystem" VS2017 v15.6 gained a new switch "/external:I" for supporting external/system include paths to prevent warning from third-party headers.
CMake should make use of it.
A closer description can be found here: https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/3.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/17724Enable HiDPI support in CPack-generated NSIS-based installers2022-10-21T10:13:02-04:00Alexander ShaduriEnable HiDPI support in CPack-generated NSIS-based installersCurrently the CPack-generated NSIS-based installers are all blurry when run on a HiDPI display. Please allow specifying the ManifestDPIAware option through CPack variables
http://nsis.sourceforge.net/Reference/ManifestDPIAware
ThanksCurrently the CPack-generated NSIS-based installers are all blurry when run on a HiDPI display. Please allow specifying the ManifestDPIAware option through CPack variables
http://nsis.sourceforge.net/Reference/ManifestDPIAware
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/21509GET_RUNTIME_DEPENDENCIES does not seem to work with MinGW2022-10-20T13:56:04-04:00Bogdan BGET_RUNTIME_DEPENDENCIES does not seem to work with MinGWHi,
I am using Arch Linux with MinGW and cmake 3.19. I have a shared library and I am trying to get its runtime dependencies:
```cmake
set(CMAKE_MINGW_SYSTEM_LIBRARY_PATH \"${CMAKE_FIND_ROOT_PATH}/bin/\")")
install(CODE [[
messa...Hi,
I am using Arch Linux with MinGW and cmake 3.19. I have a shared library and I am trying to get its runtime dependencies:
```cmake
set(CMAKE_MINGW_SYSTEM_LIBRARY_PATH \"${CMAKE_FIND_ROOT_PATH}/bin/\")")
install(CODE [[
message(STATUS "Looking for deps in ${CMAKE_SYSTEM_LIBRARY_PATH};${CMAKE_MINGW_SYSTEM_LIBRARY_PATH}")
file(GET_RUNTIME_DEPENDENCIES
RESOLVED_DEPENDENCIES_VAR deps_resolved
UNRESOLVED_DEPENDENCIES_VAR deps_unresolved
LIBRARIES $<TARGET_FILE:mylib>
DIRECTORIES ${CMAKE_SYSTEM_LIBRARY_PATH} ${CMAKE_MINGW_SYSTEM_LIBRARY_PATH}
PRE_EXCLUDE_REGEXES "api-ms-*" "ext-ms-*"
POST_EXCLUDE_REGEXES ".*system32/.*\\.dll"
)
message(STATUS "Resolving runtime dependencies for $<TARGET_FILE:mylib>")
foreach(dep ${deps_resolved})
file(INSTALL ${dep} DESTINATION ${CMAKE_INSTALL_PREFIX})
endforeach()
foreach(dep ${deps_unresolved})
message(WARNING "Runtime dependency ${dep} could not be resolved.")
endforeach()
]])
```
The variable `CMAKE_MINGW_SYSTEM_LIBRARY_PATH` points to the correct path on my system `/usr/x86_64-w64-mingw32/bin`. The code does not return anything at all (no resolved, no unresolved), it just seems that it does not find anything.
The same works fine with MSVC / cmake version 3.18.20081302-MSVC_2.
I first asked on the forum [here](https://discourse.cmake.org/t/get-runtime-dependencies-does-not-seem-to-work-with-mingw/2239) and opening this issue as instructed. I will be happy to assist with any other details.
Thanks,
Bogdanhttps://gitlab.kitware.com/cmake/cmake/-/issues/12865CPack generated archives don't have correct permissions when cross compiling ...2022-10-17T16:47:35-04:00Kitware RobotCPack generated archives don't have correct permissions when cross compiling on windowsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12865). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12865). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/24045IntelLLVM: Unable to set oneAPI-specific C++ compiler flags in combination wi...2022-10-11T13:03:25-04:00Dirk AdlerIntelLLVM: Unable to set oneAPI-specific C++ compiler flags in combination with Visual StudioHello,
I'm using Visual Studio 2022 with the Intel oneApi 2022 C++ Compiler and CMake 3.23.1. Everything works as expected expect setting some specific Intel C++ compiler flags.
E.g. For optimization Visual Studio supports Od, O1, O2 ...Hello,
I'm using Visual Studio 2022 with the Intel oneApi 2022 C++ Compiler and CMake 3.23.1. Everything works as expected expect setting some specific Intel C++ compiler flags.
E.g. For optimization Visual Studio supports Od, O1, O2 and Ox.
The Intel C++ Compiler supports Od, O1, O2, Ox and O3[Intel C++].
I can set all flags expect the O3 and some optimization diagnostic flags supported by the Intel compiler.
I tried it in multiple ways.
Changing the current flag like this:
```
MESSAGE(STATUS "CMAKE_CXX_FLAGS_RELEASE: ${CMAKE_CXX_FLAGS_RELEASE}")
string(REGEX REPLACE "/O[0-4]" "/O3" CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}" CACHE STRING "" FORCE)
MESSAGE(STATUS "CMAKE_CXX_FLAGS_RELEASE: ${CMAKE_CXX_FLAGS_RELEASE}")
```
The CXX_FLAG contains the Value O3, but when I open Visual Studio it is still set zo O2.
I also tried to overwrite the initial CXX flags
`set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX "${CMAKE_CURRENT_SOURCE_DIR}/cmake/cxx_flags_override.cmake")`
with
```
if (("${CMAKE_CXX_COMPILER_ID}" MATCHES "IntelLLVM"))
set(CMAKE_CXX_FLAGS_RELEASE_INIT "/MD /O3 /Ob2 /DNDEBUG /Qopt-report:3 /Qopt-report-phase:loop /Qopt-report-file:C:/Temp/ICX.dat")
message(STATUS "Overrides default compiler flags!")
else()
message(FATAL_ERROR "Overrides not set for compiler ${CMAKE_CXX_COMPILER_ID}")
endif()
```
but the behavior is still the same. The flag is still O2.
A minimum CMake file looks like that:
```
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX "${CMAKE_CURRENT_SOURCE_DIR}/cmake/cxx_flags_override.cmake")
project(IntelTest)
set(EXECUTABLE_NAME intelTest)
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CONFIGURATION_TYPES "Debug;Release")
add_executable(${EXECUTABLE_NAME}
main.cpp
)
```
The main is not doing anything right now:
```
#include <iostream>
#if defined( __INTEL_LLVM_COMPILER )
#endif
#if defined( _MSC_VER ) && ! defined( __INTEL_LLVM_COMPILER )
#endif
int main(int argc, char** argv)
{
std::cout << "Intel Test!!!" << std::endl;
return 0;
}
```
If I use Ninja to build the project, the flags for optimization are accepted and the diagnostic is written to file.
```
REM Set Intel C++ compiler variables
call "C:\Program Files (x86)\Intel\oneAPI\compiler\2022.2.0\env\vars.bat"
REM Create the project
cmake -G Ninja -B build-ninja -DCMAKE_MAKE_PROGRAM="ninja.exe" -DCMAKE_C_COMPILER="C:/Program Files (x86)/Intel/oneAPI/compiler/2022.2.0/windows/bin/icx.exe" -DCMAKE_CXX_COMPILER="C:/Program Files (x86)/Intel/oneAPI/compiler/2022.2.0/windows/bin/icx.exe" -DCMAKE_BUILD_TYPE=Release
cd build-ninja
REM Build the project
cmake --build . --config Release --verbose --clean-first
cd ..
```
A discussion about the topic in the CMake community can be found here:
https://discourse.cmake.org/t/intel-oneapi-c-compiler-with-visual-studio-2022/6634/3
Thanks and best regards,
Dirkhttps://gitlab.kitware.com/cmake/cmake/-/issues/9879find_program command doesn't take PATHEXT into account2022-09-23T11:55:06-04:00Kitware Robotfind_program command doesn't take PATHEXT into accountThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9879). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9879). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/23988Ninja: UTF-8 response files without BOM lead to build errors2022-09-22T14:30:56-04:00Sjard Ole KrügerNinja: UTF-8 response files without BOM lead to build errorsThe attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force ...The attached [example](/uploads/aae1fab9f65a06ee5528d0094e9a402d/test.zip) fails with Cmake 3.24.0, Ninja 1.11.0 and MSVC 2019 on a Windows 10 machine (sorry for the cluttered file structure, long paths was the only way I found to force cmake/ninja to generate a linker response file).
`LINK : fatal error LNK1181: cannot open input file 'in order to2\force cmake to\generate an rsp file\we will need\a very long path in order\to exceed the cli\argument length limit and\add some umlauts like\äöü\CMakeFiles\object.dir\addition\add_char.cpp.obj'
ninja: build stopped: subcommand failed.`
The problem seems to be closely related to #21792. If I add the BOM manually to **@CMakeFiles\component.rsp**, the linker statement is successful.https://gitlab.kitware.com/cmake/cmake/-/issues/17600CMAKE_DL_LIBS should contain "dl" on MINGW2022-09-21T14:37:07-04:00Sandro ManiCMAKE_DL_LIBS should contain "dl" on MINGWI've noticed while cross-compiling libzip to windows using Fedora's mingw toolchain that CMAKE_DL_LIBS is empty (which caused the build to failure with undefined references to dlopen & co.). I believe that CMAKE_DL_LIBS should contain dl...I've noticed while cross-compiling libzip to windows using Fedora's mingw toolchain that CMAKE_DL_LIBS is empty (which caused the build to failure with undefined references to dlopen & co.). I believe that CMAKE_DL_LIBS should contain dl. Patch attached.
[cmake-mingw-dl.patch](/uploads/a21194391caa841d30b252229e27c7a7/cmake-mingw-dl.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/23978Ninja: Optionally use powershell scripts instead of batch files for long cust...2022-09-20T13:03:08-04:00Nicholas PatellaNinja: Optionally use powershell scripts instead of batch files for long custom commandsHi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue wi...Hi, I'm using the latest CMake and ninja on Windows.
I notice that when a custom command is longer than 8192 characters, rather than be written directly to the build.ninja file, it's written to a .bat file.
I'm experiencing an issue with .bat files on a particular version of Windows that I am not sure if Microsoft will fix expediently (see Motivation).
It would be nice to have an option to be able to change the behavior of long commands to write to a PS script instead of a .bat script.
Since my arguments have generator expressions, I can't use file(WRITE).
For now, my solution is to write a PS script incrementally using multiple COMMANDs, and then finally calling that PS script, but it isn't ideal.
If CMake could support alternate ways to invoke long commands out of the box, it would be helpful.
<details><summary>Motivation</summary>
When working with add_custom_command and add_custom_target, CMake writes commands that would exceed the command line limit to a .bat file.
However, on Windows Server 2016, when executing a .bat file that contains a command longer 8192, while no error is thrown, the 8192th character is deleted from the command arguments during .bat execution, and the invoked program receives corrupt arguments. In CMake + ninja builds, the consequence is that when passing a long list of files to a custom command, one of the arguments or file paths will become corrupt.
A simple way to see this is to write:
`powershell.exe -Command "& { echo 123456789123456789 }" > output.txt`
to a .bat file, and modify the string echoed ("123456789123456789") to be longer than 8192 characters.
If you run this, you will see that output.txt is missing a character from what should have been echoed.
This issue only happens on Windows Server 2016 (I haven't tried 2019) and does not happen on the latest Windows 10 Pro.
Issue tracking on Microsoft's Feedback Hub (upvote would be appreciated):
https://aka.ms/AAi2pi7
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/23948Intel on Windows might have spaces in SDK paths2022-09-14T08:14:34-04:00Ben BoeckelIntel on Windows might have spaces in SDK pathsIntel on Windows has logic to disable `deps = gcc` usage when there are spaces in the source paths. However, the "does not properly escape spaces" can still hit if any dependencies have spaces in their paths.
Reported on Discourse: http...Intel on Windows has logic to disable `deps = gcc` usage when there are spaces in the source paths. However, the "does not properly escape spaces" can still hit if any dependencies have spaces in their paths.
Reported on Discourse: https://discourse.cmake.org/t/problems-building-project-command-line-with-intel-compiler-and-ninja-generator/6244
Relevant MR: !5557
/cc @brad.king @marc.chevrierMarc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/23882Set WINDOWS variable when running on a Windows target2022-09-07T16:04:35-04:00Cristian AdamSet WINDOWS variable when running on a Windows targetCurrently we have the `WIN32` variable for Windows, and the 32 suffix is a bit misleading for the users running on Windows x86_64 or Windows Arm64.
I have seen the documentation of [WIN32](https://cmake.org/cmake/help/latest/variable/WI...Currently we have the `WIN32` variable for Windows, and the 32 suffix is a bit misleading for the users running on Windows x86_64 or Windows Arm64.
I have seen the documentation of [WIN32](https://cmake.org/cmake/help/latest/variable/WIN32.html):
> Set to True when the target system is Windows, including Win64.
Currently there are other Windows variables set:
* WINCE
* WINDOWS_PHONE
* WINDOWS_STORE
I think the `WINDOWS` variable fits better than `WIN32`.https://gitlab.kitware.com/cmake/cmake/-/issues/23880source_group and target_sources with file_set headers conflict2022-08-25T09:14:27-04:00Bert de Vreugdsource_group and target_sources with file_set headers conflictIn one of my projects I have a cmake file, containing:
```cmake
target_sources(exampleproject
PUBLIC FILE_SET HEADERS FILES
ExampleHeader.h
PUBLIC FILE_SET examplelib TYPE HEADERS BASE_DIRS examplelib/include FILES
...In one of my projects I have a cmake file, containing:
```cmake
target_sources(exampleproject
PUBLIC FILE_SET HEADERS FILES
ExampleHeader.h
PUBLIC FILE_SET examplelib TYPE HEADERS BASE_DIRS examplelib/include FILES
${headers_examplelib}
)
source_group(TREE ${CMAKE_CURRENT_SOURCE_DIR}/examplelib/include PREFIX "Header Files/examplelib" FILES ${headers_examplelib})
```
However, if I generate a Visual Studio solution (`cmake -G "Visual Studio 17 2022" -A x64 ..`), the subgroup is not created under `Header Files` (every file will be added to the root of `Header Files`).
When I change `Header Files` to an other value ~~(including `Source Files`)~~ it will work. When adding non-header files to another subdirectory of a default source group (like `Source Files`) will also work.
My belief is that the fileset generated by target_sources somehow conflict with the settings inside source_group?3.24.2Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/23244MinGW: Honoring .manifest sources2022-08-15T12:23:29-04:00Brad KingMinGW: Honoring .manifest sourcesWith MSVC we link `.exe` and `.dll` files using special `cmake -E vs_link_exe` and `cmake -E vs_link_dll` helpers to embed `.manifest` sources by compiling them as a resource. Something similar may be needed on MinGW. This will need a ...With MSVC we link `.exe` and `.dll` files using special `cmake -E vs_link_exe` and `cmake -E vs_link_dll` helpers to embed `.manifest` sources by compiling them as a resource. Something similar may be needed on MinGW. This will need a policy to avoid colliding with projects that manually handle it with their own `.rc` files.