CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-03-08T11:45:38-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/24266IntelLLVM: env-regression: Intel oneAPI on Windows2023-03-08T11:45:38-05:00scivisionIntelLLVM: env-regression: Intel oneAPI on WindowsIntel oneAPI 2023.0.0 was released several days ago. I notice that the new compiler frontend for [Windows icpx](https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compiler-...Intel oneAPI 2023.0.0 was released several days ago. I notice that the new compiler frontend for [Windows icpx](https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compiler-setup/use-the-command-line/invoke-the-compiler.html) is getting picked up first by CMake instead of "icx", but then CMake doesn't work correctly with icpx on Windows. I noticed this with CMake 3.25.[0,1]. The root issue is an old assumption that only icx is present on Windows.
It would be nice if icpx would work with CMake on Windows, but a quick workaround is to just look for icx first on Windows.
A user workaround is to set env var `CXX=icx` or `cmake -DCMAKE_CXX_COMPILER=icx`
A minimal CMakeList.txt fails to detect the C++ compiler correctly with oneAPI 2023.0.0 on Windows:
```cmake
cmake_minimum_required(VERSION 3.19...3.26)
project(a LANGUAGES C CXX)
```
```
-- The C compiler identification is IntelLLVM 2023.0.0 with MSVC-like command-line
-- The CXX compiler identification is IntelLLVM 2023.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icpx.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icpx.exe - broken
CMake Error at C:/cmake-3.25.0/share/cmake-3.25/Modules/CMakeTestCXXCompiler.cmake:63 (message):
The C++ compiler
"C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icpx.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/temp/buildi/CMakeFiles/CMakeScratch/TryCompile-7dpaqo
Run Build Command(s):C:/msys64/mingw64/bin/ninja.exe cmTC_7d301 && [1/2] Building CXX object CMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj
FAILED: CMakeFiles/cmTC_7d301.dir/testCXXCompiler.cxx.obj
C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin\icpx.exe /nologo /TP /DWIN32 /D_WINDOWS /EHsc /Ob0 /Od /RTC1 -MDd -Zi -QMD -QMT CMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj -QMF CMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj.d /FoCMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj /FdCMakeFiles\cmTC_7d301.dir\ -c C:\temp\buildi\CMakeFiles\CMakeScratch\TryCompile-7dpaqo\testCXXCompiler.cxx
icpx: error: unknown argument: '-nologo'
icpx: error: unknown argument: '-EHsc'
icpx: error: unknown argument: '-MDd'
icpx: error: unknown argument: '-Zi'
icpx: error: unknown argument: '-QMD'
icpx: error: unknown argument: '-QMT'
icpx: error: unknown argument: '-QMF'
icpx: error: no such file or directory: 'CMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj'
icpx: error: no such file or directory: 'CMakeFiles\cmTC_7d301.dir\testCXXCompiler.cxx.obj.d'
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
```
For reference:
```pwsh
dir "C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/*.exe"
```
```
Directory: C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\bin
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 12/1/2022 09:03 680488 aocl-ioc64.exe
-a--- 12/1/2022 09:03 427048 dpcpp-cl.exe
-a--- 12/1/2022 09:03 427048 dpcpp.exe
-a--- 12/1/2022 09:03 416808 fpp.exe
-a--- 12/1/2022 09:03 1337896 icpx.exe
-a--- 12/1/2022 09:03 1339944 icx-cc.exe
-a--- 12/1/2022 09:03 1339944 icx-cl.exe
-a--- 12/1/2022 09:03 1339944 icx.exe
-a--- 12/1/2022 09:03 1355304 ifx.exe
-a--- 12/1/2022 09:03 680488 ioc64.exe
-a--- 12/1/2022 09:03 759336 opencl-aot.exe
-a--- 12/1/2022 09:03 417320 sycl-ls.exe
-a--- 12/1/2022 09:03 11938344 sycl-post-link.exe3.24.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24251Windows: Option to add SOVERSION to DLL names2023-02-28T08:29:23-05:00rhabackerWindows: Option to add SOVERSION to DLL namesWith VulkanSceneGraph there is a [request](https://github.com/vsg-dev/VulkanSceneGraph/pull/663) to create versioned shared libraries with MinGW by adding a SOVERSION-based suffix to the output filename, such as is common with MinGW pack...With VulkanSceneGraph there is a [request](https://github.com/vsg-dev/VulkanSceneGraph/pull/663) to create versioned shared libraries with MinGW by adding a SOVERSION-based suffix to the output filename, such as is common with MinGW packages on an openSUSE distribution [see related thread] (https://github.com/vsg-dev/VulkanSceneGraph/pull/663#issuecomment-1353206334).
The vsg maintainer pointed out that this would be better solved in cmake after all:
https://github.com/vsg-dev/VulkanSceneGraph/pull/663#issuecomment-1353024214
> I assume other CMake users have the same problem on MinGW/Windows, so maybe CMake itself could provide the behavior instead of replicating it in our local CMake scripts.https://gitlab.kitware.com/cmake/cmake/-/issues/24416VS: Wrong appxManifest if OUTPUT_NAME != target name2023-02-17T08:53:16-05:00SergeyVS: Wrong appxManifest if OUTPUT_NAME != target nameCMakeLists.txt:
```cmake
project(test)
add_executable(test test.c)
set_target_properties(test PROPERTIES OUTPUT_NAME app)
```
test.c:
```c
int main() {
}
```
Run:
```
cmake -S . -B out -D CMAKE_SYSTEM_NAME=WindowsStore -D CMAKE_SYSTEM_V...CMakeLists.txt:
```cmake
project(test)
add_executable(test test.c)
set_target_properties(test PROPERTIES OUTPUT_NAME app)
```
test.c:
```c
int main() {
}
```
Run:
```
cmake -S . -B out -D CMAKE_SYSTEM_NAME=WindowsStore -D CMAKE_SYSTEM_VERSION=10.0
```
Result out/test.dir/package.appxManifest:
```xml
<?xml version="1.0" encoding="utf-8"?>
<Package
xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
IgnorableNamespaces="uap mp">
<Identity Name="33AD70F9-17D8-32F6-9C92-D5EEB7D9D699" Publisher="CN=CMake" Version="1.0.0.0" />
<mp:PhoneIdentity PhoneProductId="33AD70F9-17D8-32F6-9C92-D5EEB7D9D699" PhonePublisherId="00000000-0000-0000-0000-000000000000"/>
<Properties>
<DisplayName>test</DisplayName>
<PublisherDisplayName>CMake</PublisherDisplayName>
<Logo>test.dir\StoreLogo.png</Logo>
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
</Dependencies>
<Resources>
<Resource Language="x-generate" />
</Resources>
<Applications>
<Application Id="App" Executable="test.exe" EntryPoint="test.App">
<uap:VisualElements
DisplayName="test"
Description="test"
BackgroundColor="#336699"
Square150x150Logo="test.dir\Logo.png"
Square44x44Logo="test.dir\SmallLogo44x44.png">
<uap:SplashScreen Image="test.dir\SplashScreen.png" />
</uap:VisualElements>
</Application>
</Applications>
</Package>
```
This results in `cmake --build out` error:
```
out\test.dir\package.appxManifest : error APPX0703: Manifest references file 'test.exe' which is not part of the payload.
```
The issue:
```xml
<Application Id="App" Executable="test.exe" EntryPoint="test.App">
```
must be
```xml
<Application Id="App" Executable="app.exe" EntryPoint="app.App">
```
I suppose the reason is [Source/cmVisualStudio10TargetGenerator.cxx#L5321-L5322](https://github.com/Kitware/CMake/blob/7ac338be9830bdc936b52a4135504ed011418f3c/Source/cmVisualStudio10TargetGenerator.cxx#L5321-L5322)
```cpp
std::string targetNameXML =
cmVS10EscapeXML(this->GeneratorTarget->GetName());
```
and maybe a wrong test case [Tests/VSWinStorePhone/cmake/Package_vc14.store.appxmanifest.in#L25](https://github.com/Kitware/CMake/blob/859241d2bbaae83f06c44bc21ab0dbd38725a3fc/Tests/VSWinStorePhone/cmake/Package_vc14.store.appxmanifest.in#L25)
```xml
<Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="@SHORT_NAME@.App">
```
[CMakeLists.txt](/uploads/37ea78e1dd0b7fb2a3c601e1f004bac7/CMakeLists.txt)[test.c](/uploads/60a89a44e8c68c3609f9c63d7f107be3/test.c)[package.appxManifest](/uploads/b48b902b8828167a4d60448aa1de290d/package.appxManifest)https://gitlab.kitware.com/cmake/cmake/-/issues/24036Annoying behavior of `CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=ON` on Windows h...2023-01-18T09:49:19-05:00EgorAnnoying behavior of `CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=ON` on Windows hostsI'm trying to use `PATH` only for finding programs, and nothing else.
But on Windows this doesn't work. There, CMake seems to search the parent of each directory in the `PATH` as a prefix.
I found the culprit in `cmFindBase::FillSystem...I'm trying to use `PATH` only for finding programs, and nothing else.
But on Windows this doesn't work. There, CMake seems to search the parent of each directory in the `PATH` as a prefix.
I found the culprit in `cmFindBase::FillSystemEnvironmentPath()`:
```cpp
#if defined(_WIN32) || defined(__CYGWIN__)
paths.AddEnvPrefixPath("PATH", true);
#endif
```
I think I see the rationale behind this, but I think it would be good to have a flag to disable this behavior.
---
I tried setting `CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=OFF` and `CMAKE_PROGRAM_PATH` to the contents of `PATH`, but it causes more problems (my binutils are in a custom directory, and `CMakeFindBinUtils.cmake` ignores `CMAKE_PROGRAM_PATH`).
I'm also forced to use `CMAKE_FIND_USE_CMAKE_SYSTEM_PATH=OFF`, because enabling it extracts the paths from `PATH` too.https://gitlab.kitware.com/cmake/cmake/-/issues/24316IntelLLVM: Windows: emits -Qstd=c++11 that causes compiler warnings2023-01-13T08:43:35-05:00scivisionIntelLLVM: Windows: emits -Qstd=c++11 that causes compiler warningsWindows IntelLLVM emits `-Qstd=` flags that cause compiler warnings. This is annoying in general and a problem when using COMPILE_WARNING_AS_ERROR.
This is observed with generators MinGW Makefiles and Ninja. This is not observed with ge...Windows IntelLLVM emits `-Qstd=` flags that cause compiler warnings. This is annoying in general and a problem when using COMPILE_WARNING_AS_ERROR.
This is observed with generators MinGW Makefiles and Ninja. This is not observed with generator Visual Studio 17 2022.
However, @brad.king notes that
> We *strongly* prefer the `-` style options over `/` because they work better with makefiles that use the MSYS shell.
```cmake
cmake_minimum_required(VERSION 3.21)
project(dummy LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 11)
set(cpp_src "${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp")
file(WRITE ${cpp_src} "int main() { return 0; }")
add_executable(dummy_cpp ${cpp_src})
```
```
-- The CXX compiler identification is IntelLLVM 2023.0.0 with MSVC-like command-line
```
Ninja:
```
[1/2] Building CXX object CMakeFiles\dummy_cpp.dir\dummy.cpp.obj
icx: warning: argument unused during compilation: '-Qstd:c++11' [-Wunused-command-line-argument]
[2/2] Linking CXX executable dummy_cpp.exe
```
MinGW Makefiles:
```
[ 50%] Building CXX object CMakeFiles/dummy_cpp.dir/dummy.cpp.obj
icx: warning: argument unused during compilation: '-Qstd=c++11' [-Wunused-command-line-argument]
[100%] Linking CXX executable dummy_cpp.exe
[100%] Built target dummy_cpp
```3.25.2https://gitlab.kitware.com/cmake/cmake/-/issues/21866Ninja: 1.11 will expect UTF-8 encoding on Windows2022-12-14T14:31:29-05:00Brad KingNinja: 1.11 will expect UTF-8 encoding on Windows[Ninja PR 1915](https://github.com/ninja-build/ninja/pull/1915) converts Ninja to expect UTF-8 encoding in `build.ninja` files when running on Windows 10 1903 or higher. CMake will need to be updated to account for this when generating ...[Ninja PR 1915](https://github.com/ninja-build/ninja/pull/1915) converts Ninja to expect UTF-8 encoding in `build.ninja` files when running on Windows 10 1903 or higher. CMake will need to be updated to account for this when generating `build.ninja` and friends.
Additionally, [this comment](https://github.com/ninja-build/ninja/pull/1915#issuecomment-784365759) points out that we may need to update the `showIncludes` prefix handling. We may need to convert the string extracted from `cl`'s output into UTF-8 to bytewise match what is in `build.ninja`. There is relevant code in CMake [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0-rc2/Source/cmLocalNinjaGenerator.cxx#L91-104).Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/23841Modules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windres2022-11-28T17:52:39-05:00B. Scott MichelModules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windresI just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. T...I just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. There have been proposals to do this for Windows-native, but it's never been done AFAIK.
The "solution" is to manually copy `windres` to `<toolchain prefix>-windres`, which is really suboptimal and breaks packaging badly.
This change now breaks all of my MinGW builds on Windows.3.24.1Brad KingBrad Kinghttps://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/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/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/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/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/23836IPO: gcc -flto=auto breaks linking on Windows2022-08-15T10:48:31-04:00Brad KingIPO: gcc -flto=auto breaks linking on Windows!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.3.24.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23741IntelLLVM: IPO fails on Windows2022-08-04T09:50:25-04:00Martin BlanchardIntelLLVM: IPO fails on WindowsThe CMake sample below fails on Windows with MSVC 2019 (16.11.7) + IntelLLVM 2022.1 (2022.1.0.20220316):
```cmake
cmake_minimum_required(
VERSION 3.24.0)
set(CMAKE_C_COMPILER "icx")
set(CMAKE_CXX_COMPILER "icx")
enable_language(C CX...The CMake sample below fails on Windows with MSVC 2019 (16.11.7) + IntelLLVM 2022.1 (2022.1.0.20220316):
```cmake
cmake_minimum_required(
VERSION 3.24.0)
set(CMAKE_C_COMPILER "icx")
set(CMAKE_CXX_COMPILER "icx")
enable_language(C CXX)
project(CMake-IntelLLVM-WIN32)
include(CheckIPOSupported)
check_ipo_supported()
```
Ran like:
```bat
cmake -G Ninja -B build\ .
```
Gives:
```
-- The C compiler identification is IntelLLVM 2022.1.0 with MSVC-like command-line
-- The CXX compiler identification is IntelLLVM 2022.1.0 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at D:/.../cmake-3.24/Modules/CheckIPOSupported.cmake:68 (message):
IPO is not supported (CMake doesn't support IPO for current CXX compiler).
Call Stack (most recent call first):
D:/.../cmake-3.24/Modules/CheckIPOSupported.cmake:245 (_ipo_not_supported)
CMakeLists.txt:12 (check_ipo_supported)
-- Configuring incomplete, errors occurred!
See also "D:/.../build/CMakeFiles/CMakeOutput.log".
```
[CMakeOutput.log](/uploads/aa30b9d436e9e04640f177a2fbcfd680/CMakeOutput.log)3.25.0https://gitlab.kitware.com/cmake/cmake/-/issues/23781cmake -E create_symlink with .. in path create broken junction2022-08-02T09:28:54-04:00Dusan Poizlcmake -E create_symlink with .. in path create broken junctionHello,
we are using cmake -E create_symlink in our project. Up until now it was working fine but with 3.24 we encountered problem on Windows with it.
we are calling it with "${CMAKE_SOURCE_DIR}/../UserData" as target to link. This is wor...Hello,
we are using cmake -E create_symlink in our project. Up until now it was working fine but with 3.24 we encountered problem on Windows with it.
we are calling it with "${CMAKE_SOURCE_DIR}/../UserData" as target to link. This is working fine with older releases at it create symlink. With 3.24 it create junction which is not problem itself it just that junction doesn't like ".." in its path. I think cmake -E create_symlink should always create symlink on windows or normalize path when creating junction.3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23066Clang: duplicate resource: type MANIFEST for GNU Windows build2022-07-20T09:09:39-04:00djdronClang: duplicate resource: type MANIFEST for GNU Windows buildRelated to #22611.
As described in [this note](https://gitlab.kitware.com/cmake/cmake/-/issues/22611#note_1098039)Related to #22611.
As described in [this note](https://gitlab.kitware.com/cmake/cmake/-/issues/22611#note_1098039)