CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-14T09:18:35-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25764FindPython3: add support for Python3_FIND_ABI under Windows2024-03-14T09:18:35-04:00LE GARREC VincentFindPython3: add support for Python3_FIND_ABI under WindowsDocumentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pyde...Documentation says : "So, on Windows systems, when Python3_FIND_ABI is defined, Python distributions from python.org will be found only if value for each flag is OFF or ANY."
I tried to implement a workaround because I need to have pydebug to use pybind11 in Debug mode : [Windows Python with Debug Libraries Installed causes linker error](https://github.com/pybind/pybind11/issues/3403)
List of problems I found :
- If I set `Python3_FIND_ABI(ON ANY ANY)`, `Python3_FIND_UNVERSIONED_NAMES` search `python` instead of `pythond` / `python_d`.
- `sys.abiflags` doesn't work for Windows. So don't try to read `sys.abiflags` to check if an interpreter is good. Also don't update `Python3_ABIFLAGS` when interpreter has been checked.
- `Changed in version 3.8: Default flags became an empty string (m flag for pymalloc has been removed).
` [System-specific parameters and functions](https://docs.python.org/3/library/sys.html). I didn't do any change about this change.https://gitlab.kitware.com/cmake/cmake/-/issues/25731CMake does not support C++20 modules with clang-cl.exe2024-03-05T06:02:25-05:00Sharadh RajaramanCMake does not support C++20 modules with clang-cl.exeSupplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may us...Supplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may use modules, but the
compiler does not provide a way to discover the import graph dependencies.
See the cmake-cxxmodules(7) manual for details. Use the
CMAKE_CXX_SCAN_FOR_MODULES variable to enable or disable scanning.
```
`clang-cl.exe` is in fact _exactly_ (read: bit-for-bit equal, and therefore have equal file checksums) the same binary as `clang.exe` in the official LLVM distribution for Windows, with only differing file names. It is able to [forward arguments to the GNU-style driver with `/clang:`](https://github.com/llvm/llvm-project/blob/051e910b8b6c59fc94d019fa01ae4507b1c81498/clang/docs/UsersManual.rst#L4397), and therefore [straightforwardly supports C++20 module compilation](https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257/28) equally as well as the latter.https://gitlab.kitware.com/cmake/cmake/-/issues/25639CMake doesn't respect 8.3 short paths for source and build directory2024-02-01T09:33:54-05:00Cristian AdamCMake doesn't respect 8.3 short paths for source and build directory### Preamble
In order to have support for long paths on Windows CMake needs to support short paths first.
### Long paths support for Windows
Windows has support for long paths (>255 characters) since Windows 10 version 1607 released o...### Preamble
In order to have support for long paths on Windows CMake needs to support short paths first.
### Long paths support for Windows
Windows has support for long paths (>255 characters) since Windows 10 version 1607 released on August 2015. But the applications need to [opt-in](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later) in order to use the new functionality.
The Visual C++ compiler has been developed in the nineties and the reported [issue](https://developercommunity.visualstudio.com/t/compiler-cant-find-source-file-in-path-/10221576) is being considered but not yet fixed (Jan 2024).
Ninja build system has been [fixed](https://github.com/ninja-build/ninja/pull/2225) but the 1.12.0 release has not been made, latest release was [v1.11.1](https://github.com/ninja-build/ninja/releases/tag/v1.11.1) on Aug 30, 2022.
### Qt Applications Windows problem
At [QTCREATORBUG-26786](https://bugreports.qt.io/browse/QTCREATORBUG-26786) there is an issue compiling Qt Creator itself.
At [QTBUG-117413](https://bugreports.qt.io/browse/QTBUG-117413) there is a bug report with a broader Qt application issue.
This is an issue since user cannot compile Qt applications on Windows with the recommended Visual C++ toolchain.
### Small Hello World example
Let's say we have this `main.cpp` C++ Hello World program:
```cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello Long Path Windows World!" << endl;
return 0;
}
```
and a `CMakeLists.txt` like this:
```cmake
cmake_minimum_required(VERSION 3.5)
project(HelloWorld LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(HelloWorld main.cpp)
include(GNUInstallDirs)
install(TARGETS HelloWorld
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
)
```
These two files are located in the following path:
```plaintext
C:\Projects\ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
```
Then I've tried the following configure command:
```plaintext
$ cmake -S HelloWorld -B build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug -GNinja -DCMAKE_BUILD_TYPE=Debug
```
This fails due to long path support missing from `cl.exe` and `ninja.exe`:
<details>
<summary>
configuration error message
</summary>
<pre>
$ cmake -S HelloWorld -B build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe
CMake Warning in C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom/CMakeLists.txt:
The object file directory
C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom/CMakeFiles/cmTC_87735.dir/./
has 279 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
testCXXCompiler.cxx.obj
cannot be safely placed under this directory. The build may not work
correctly.
CMake Error:
Running
'C:/Tools/Ninja/ninja.exe' '-C' 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-qo4hom' '-t' 'recompact'
failed with:
ninja: error: loading 'build.ninja': The system cannot find the path specified.
CMake Error at C:/Program Files/CMake/share/cmake-3.28/Modules/CMakeTestCXXCompiler.cmake:49 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
C:\Projects\ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
</pre>
</details>
### Short 8.3 paths
CMake has already instances of using 8.3 short paths for [Ninja for the C/C++ compiler path](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmNinjaTargetGenerator.cxx#L875) and for a [Visual C++ 6.0 linker issue](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmMSVC60LinkLineComputer.cxx#L31)
Aimed with this information I've had a look at how the 8.3 short paths would look like:
```plaintext
26/01/2024 13:36 <DIR> THISPA~1 ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters
Directory of C:\Projects\THISPA~1
26/01/2024 14:45 <DIR> BUILD-~1 build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug
26/01/2024 14:10 <DIR> HELLOW~1 HelloWorld
```
My expectation was that if I provide short 8.3 names CMake would simply work:
```
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
```
<details>
<summary>
configuration error message
</summary>
<pre>
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe
CMake Warning in C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga/CMakeLists.txt:
The object file directory
C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga/CMakeFiles/cmTC_e312f.dir/./
has 279 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
testCXXCompiler.cxx.obj
cannot be safely placed under this directory. The build may not work
correctly.
CMake Error:
Running
'C:/Tools/Ninja/ninja.exe' '-C' 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug/CMakeFiles/CMakeScratch/TryCompile-obxgga' '-t' 'recompact'
failed with:
ninja: error: loading 'build.ninja': The system cannot find the path specified.
CMake Error at C:/Program Files/CMake/share/cmake-3.28/Modules/CMakeTestCXXCompiler.cmake:49 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
</pre>
</details>
### Short 8.3 path 'simulation'
Then I decided to move the long path directory somewhere else and create the short paths explicitly (created `THISPA~1`, `HELLOW~1` and `BUILD-~1`)
The configuration worked as expected:
```plaintext
C:\Projects\THISPA~1
$ cmake -S c:\Projects\THISPA~1\HELLOW~1 -B c:\projects\THISPA~1\BUILD-~1 -GNinja -DCMAKE_BUILD_TYPE=Debug
-- The CXX compiler identification is MSVC 19.38.33134.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.38.33130/bin/Hostarm64/arm64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.9s)
-- Generating done (0.0s)
-- Build files have been written to: C:/Projects/THISPA~1/BUILD-~1
```
Then I've copied the content of the short build directory into the long directory and swapped back the long path directory.
Building worked as expected since all paths are short paths:
```plaintext
C:\Projects\THISPA~1
$ cmake --build BUILD-~1 --verbose
Change Dir: 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug'
Run Build Command(s): C:/Tools/Ninja/ninja.exe -v
[1/2] C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1438~1.331\bin\HOSTAR~1\arm64\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 -std:c++17 /showIncludes /FoCMakeFiles\HelloWorld.dir\main.cpp.obj /FdCMakeFiles\HelloWorld.dir\ /FS -c C:\Projects\THISPA~1\HELLOW~1\main.cpp
[2/2] C:\Windows\system32\cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\HelloWorld.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2022\BUILDT~1\VC\Tools\MSVC\1438~1.331\bin\HOSTAR~1\arm64\link.exe /nologo CMakeFiles\HelloWorld.dir\main.cpp.obj /out:HelloWorld.exe /implib:HelloWorld.lib /pdb:HelloWorld.pdb /version:0.0 /machine:ARM64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
C:\Projects\THISPA~1
$ cmake --build BUILD-~1 --verbose
Change Dir: 'C:/Projects/ThisPathWasArtificiallyMadeLongInOrderToTestHowAWindowsCompilerWouldBehaveWhenHavingAPathLongerThanWhatMAXPATHIsAllowingNamelyLongerThan255Characters/build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug'
Run Build Command(s): C:/Tools/Ninja/ninja.exe -v
ninja: no work to do.
C:\Projects\THISPA~1
$ build-HelloWorld-Qt_6_6_0_msvc2022_arm64-Debug\HelloWorld.exe
Hello Long Path Windows World!
```
### Conclusion
If CMake would support short 8.3 paths it would also support long paths and help A LOT of Windows users that complain about this.
Tools like Qt Creator would then give the 8.3 paths for the `-S` and `-B` parameters and the CMake would just do its job! :smile:
### Note
Also posted [on discourse](https://discourse.cmake.org/t/9941).https://gitlab.kitware.com/cmake/cmake/-/issues/25573ci: Incomplete testing for CMake's Swift support on Windows2024-02-09T09:17:21-05:00Brad Kingci: Incomplete testing for CMake's Swift support on WindowsCMake's CI pipelines ~~do not cover~~ do not fully cover Swift on Windows.CMake's CI pipelines ~~do not cover~~ do not fully cover Swift on Windows.https://gitlab.kitware.com/cmake/cmake/-/issues/254733.28.0-rc6: execute_process now finds extension-less commands in PATH on Windows2023-12-05T09:21:19-05:00Brad King3.28.0-rc6: execute_process now finds extension-less commands in PATH on WindowsThe fix in !9017 for #25450 broke
```cmake
execute_process(COMMAND cmd ...)
```
on Windows in a MSYS2 environment. The problem is that an extension-less `cmd` tool is in the `PATH`, but it is a shell script with a shebang line, and we...The fix in !9017 for #25450 broke
```cmake
execute_process(COMMAND cmd ...)
```
on Windows in a MSYS2 environment. The problem is that an extension-less `cmd` tool is in the `PATH`, but it is a shell script with a shebang line, and we cannot run it from a native Windows calling process.
I've also posted this information in upstream [libuv PR 4241](https://github.com/libuv/libuv/pull/4241#pullrequestreview-1763163945), which !9017 backported.3.28.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/254503.28.0-rc5: execute_process no longer supports executables without any extension2023-12-04T14:58:35-05:00Alexander Neumann3.28.0-rc5: execute_process no longer supports executables without any extensionvcpkg CI run with 3.28-rc5 still shows regressions:
https://github.com/microsoft/vcpkg/pull/35326
I am mostly concerned about the ryu build failure since this seems to be related to a subtle change how `execute_process` treats directori...vcpkg CI run with 3.28-rc5 still shows regressions:
https://github.com/microsoft/vcpkg/pull/35326
I am mostly concerned about the ryu build failure since this seems to be related to a subtle change how `execute_process` treats directories or similar.
The command is:
```
"E:/vcpkg_folders/new_master/installed/x64-windows-release/tools/bazel
--batch build --cpu=x64_windows --conlyopt=-nologo --conlyopt=-DWIN32
--conlyopt=-D_WINDOWS --conlyopt=-W3 --conlyopt=-utf-8 --conlyopt=-MP
--conlyopt=-MD --conlyopt=-O2 --conlyopt=-Oi --conlyopt=-Gy
--conlyopt=-DNDEBUG --conlyopt=-Z7 --linkopt=-machine:x64 --linkopt=-nologo
--linkopt=-DEBUG --linkopt=-INCREMENTAL:NO --linkopt=-OPT:REF
--linkopt=-OPT:ICF --verbose_failures --strategy=CppCompile=standalone
//ryu //ryu:ryu_printf"
```
The error is:
`no such file or directory`
Using CMake 3.27.1 the port simply builds3.28.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/25431CMake 3.28: Project using C++20 modules fails to build when using Ninja (/Mul...2023-11-20T08:00:47-05:00ZingamCMake 3.28: Project using C++20 modules fails to build when using Ninja (/MultiConfig) generator on WindowsThe attached sample project uses C++20 presets on Windows. I am using the latest Visual Studio 2022 Preview to build the project.
The project has a few CMake presets Ninja, Ninja-MultiConfig and Visual Studio 17 2022
If I use the built-i...The attached sample project uses C++20 presets on Windows. I am using the latest Visual Studio 2022 Preview to build the project.
The project has a few CMake presets Ninja, Ninja-MultiConfig and Visual Studio 17 2022
If I use the built-in CMake 3.27 + Ninja generator or a Visual 2022 the project builds. If I use an external CMake 3.28 + Ninja the project fails to build. Visual Studio Code + the respective extensions yield the same result.
The output when "Ninja (MSVC)" CMake presets is selected:
```
>------ Rebuild All started: Project: RToolBoxTest, Configuration: default.ninja.msvc ------
[1/1] Cleaning all built files...
Cleaning... 0 files.
[1/11] Scanning X:\GitHub\RToolBoxTest\RToolBox\modules\RToolBox.cppm for CXX dependencies
RToolBox.cppm
[2/11] Scanning X:\GitHub\RToolBoxTest\RToolBox\modules\System\Window.cppm for CXX dependencies
Window.cppm
[3/11] Building RC object examples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\__\Resources\Windows\SampleGame.rc.res
[4/11] Generating CXX dyndep file CMakeFiles\RToolBox.dir\CXX.dd
[5/11] Building CXX object examples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\src\main.cpp.obj
FAILED: examples/SimpleGameMain/CMakeFiles/SimpleGameMain.dir/src/main.cpp.obj
"C:\PROGRA~1\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.39.33218\bin\Hostx64\x64\cl.exe" /nologo /TP -DNOATOM -DNOCLIPBOARD -DNOCOMM -DNOCTLMGR -DNODEFERWINDOWPOS -DNODRAWTEXT -DNOGDICAPMASKS -DNOHELP -DNOICONS -DNOKANJI -DNOKERNEL -DNOKEYSTATES -DNOMCX -DNOMEMMGR -DNOMENUS -DNOMETAFILE -DNOMINMAX -DNONLS -DNOOPENFILE -DNOPROFILER -DNORASTEROPS -DNOSCROLL -DNOSERVICE -DNOSOUND -DNOSYSCOMMANDS -DNOSYSMETRICS -DNOTEXTMETRIC -DNOWH -DNOWINOFFSETS -DOEMRESOURCE -DSTRICT -DUNICODE -DWIN32_LEAN_AND_MEAN -D_UNICODE -IX:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\.. /DWIN32 /D_WINDOWS /EHsc /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /JMC /showIncludes /Foexamples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\src\main.cpp.obj /Fdexamples\SimpleGameMain\CMakeFiles\SimpleGameMain.dir\ /FS -c X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(6): error C2230: could not find module 'rmm.RToolBox'
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C3083: 'rmm': the symbol to the left of a '::' must be a type
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C2039: 'rtoolbox': is not a member of '`global namespace''
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(10): error C2878: 'rtoolbox': a namespace or class of this name does not exist
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2653: 'rt': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'Window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2146: syntax error: missing ';' before identifier 'window'
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2653: 'rt': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(17): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(19): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(21): error C2065: 'window': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\examples\SimpleGameMain\src\main.cpp(22): error C2065: 'window': undeclared identifier
[6/11] Building CXX object CMakeFiles\RToolBox.dir\modules\System\Platforms\Window_Windows.cpp.obj
FAILED: CMakeFiles/RToolBox.dir/modules/System/Platforms/Window_Windows.cpp.obj
"C:\PROGRA~1\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.39.33218\bin\Hostx64\x64\cl.exe" /nologo /TP -DNOATOM -DNOCLIPBOARD -DNOCOMM -DNOCTLMGR -DNODEFERWINDOWPOS -DNODRAWTEXT -DNOGDICAPMASKS -DNOHELP -DNOICONS -DNOKANJI -DNOKERNEL -DNOKEYSTATES -DNOMCX -DNOMEMMGR -DNOMENUS -DNOMETAFILE -DNOMINMAX -DNONLS -DNOOPENFILE -DNOPROFILER -DNORASTEROPS -DNOSCROLL -DNOSERVICE -DNOSOUND -DNOSYSCOMMANDS -DNOSYSMETRICS -DNOTEXTMETRIC -DNOWH -DNOWINOFFSETS -DOEMRESOURCE -DSTRICT -DUNICODE -DWIN32_LEAN_AND_MEAN -D_UNICODE /DWIN32 /D_WINDOWS /EHsc /Ob0 /Od /RTC1 -std:c++latest -MDd -Zi /JMC /showIncludes /FoCMakeFiles\RToolBox.dir\modules\System\Platforms\Window_Windows.cpp.obj /FdCMakeFiles\RToolBox.dir\RToolBox.pdb /FS -c X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(10): error C2230: could not find module 'rmm.RToolBox'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(15): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(18): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(18): error C2061: syntax error: identifier 'Description'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(29): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(29): error C2061: syntax error: identifier 'ResourceID'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C3646: 'description': unknown override specifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(42): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(45): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(45): error C7550: 'rmm::rtoolbox::Implementation::{ctor}': the qualified name in this context names a constructor, not a type
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(46): error C2065: 'description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(47): error C2062: type 'void' unexpected
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(48): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2059: syntax error: '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(49): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(66): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(75): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(81): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(88): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(112): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2761: 'void rmm::rtoolbox::Implementation::SetIcon(void) noexcept const': redeclaration of member is not allowed
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2065: 'ResourceID': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(118): error C2146: syntax error: missing ')' before identifier 'icon'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(119): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(119): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(127): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(154): error C3536: 'titleStr': cannot be used before it is initialized
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(161): error C2660: 'CreateWindowExW': function does not take 10 arguments
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winuser.h(4437): note: see declaration of 'CreateWindowExW'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(161): note: while trying to match the argument list '(int, long, int, int, int, int, nullptr, nullptr, HMODULE, nullptr)'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window_Windows.cpp(179): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2653: 'Window': is not a class or namespace name
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2065: 'Description': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(4): error C2062: type 'void' unexpected
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(5): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(5): error C2065: 'data': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2059: syntax error: '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(6): error C2447: '{': missing function header (old-style formal list?)
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(9): warning C4508: 'rmm::rtoolbox::{dtor}': function should return a value; 'void' return type assumed
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(12): error C2270: 'Hide': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(18): error C2270: 'Show': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(24): error C2270: 'Run': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(30): error C2270: 'GetHandle': modifiers not allowed on nonmember functions
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2825: 'rmm::rtoolbox::Window': must be a class or namespace when followed by '::'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2510: 'Window': left of '::' must be a class/struct/union
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2182: 'SetIcon': this use of 'void' is not valid
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2065: 'ResourceID': undeclared identifier
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(36): error C2146: syntax error: missing ')' before identifier 'icon'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(37): error C2143: syntax error: missing ';' before '{'
X:\GitHub\RToolBoxTest\RToolBox\modules\System\Platforms\Window.inc(37): error C2447: '{': missing function header (old-style formal list?)
[7/11] Building CXX object CMakeFiles\RToolBox.dir\modules\System\Window.cppm.obj
Window.cppm
[8/11] Building CXX object libraries\RTMain\CMakeFiles\RToolBox-main.dir\src\RTMain.cpp.obj
ninja: build stopped: subcommand failed.
Rebuild All failed.
```
This is the output when using CMake presets "MSBuild (MSVC)"
```
>------ Rebuild All started: Project: RToolBoxTest, Configuration: default.msbuild.msvc ------
MSBuild version 17.9.0-preview-23551-05+34ae4f308 for .NET Framework
MSBuild version 17.9.0-preview-23551-05+34ae4f308 for .NET Framework
1>Checking Build System
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/CMakeLists.txt
Scanning sources for module dependencies...
RToolBox.cppm
Window.cppm
Compiling...
Window.cppm
RToolBox.cppm
Window_Windows.cpp
RToolBox.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\Debug\RToolBox.lib
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/libraries/RTMain/CMakeLists.txt
RTMain.cpp
RToolBox-main.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\libraries\RTMain\RToolBox-main.dir\Debug\RToolBox-main.lib
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/examples/SimpleGameMain/CMakeLists.txt
main.cpp
SimpleGameMain.vcxproj -> X:\GitHub\RToolBoxTest\build\default.msbuild.msvc\examples\SimpleGameMain\Debug\SimpleGameMain.exe
Building Custom Rule X:/GitHub/RToolBoxTest/RToolBox/CMakeLists.txt
Rebuild All succeeded.
```https://gitlab.kitware.com/cmake/cmake/-/issues/25355cmcldeps regression: rc compilation fails2023-10-24T08:40:12-04:00Ben Boeckelcmcldeps regression: rc compilation failsThere's a report [on `vcpkg`](https://github.com/microsoft/vcpkg/issues/34597) related to compiling `zlib` where !8665 caused a regression in `cmcldeps`. More investigation necessary.
This was also discussed [on discourse](https://disco...There's a report [on `vcpkg`](https://github.com/microsoft/vcpkg/issues/34597) related to compiling `zlib` where !8665 caused a regression in `cmcldeps`. More investigation necessary.
This was also discussed [on discourse](https://discourse.cmake.org/t/9230).
Cc: @kyle.edwards @brad.king3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25352Ninja/MSVC: Always rebuilds if project path contains non-ascii characters (um...2023-10-20T10:58:50-04:00NickNinja/MSVC: Always rebuilds if project path contains non-ascii characters (umlauts, etc.)I tested building the exact same project both inside a dir with and without an umlaut in the path. Without the umlaut in the path the project builds once and runs after the build has finished, as expected. With the umlaut in the path the...I tested building the exact same project both inside a dir with and without an umlaut in the path. Without the umlaut in the path the project builds once and runs after the build has finished, as expected. With the umlaut in the path the project builds every single time, even if there are no code changes.
Tested with CMake version 3.26.4https://gitlab.kitware.com/cmake/cmake/-/issues/25194Misleading property and variable names and docs for Windows SDK version2023-08-18T12:08:25-04:00Craig ScottMisleading property and variable names and docs for Windows SDK versionI've been reviewing the documentation and behavior of the following to get a deeper understanding of how they affect Windows builds:
* Policy [CMP0149](https://cmake.org/cmake/help/latest/policy/CMP0149.html).
* The [VS_WINDOWS_TARGET_P...I've been reviewing the documentation and behavior of the following to get a deeper understanding of how they affect Windows builds:
* Policy [CMP0149](https://cmake.org/cmake/help/latest/policy/CMP0149.html).
* The [VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION](https://cmake.org/cmake/help/latest/prop_tgt/VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION.html) target property and its associated [CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION.html) variable.
* The [CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM.html) variable.
* The [CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION](https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html) variable (this one should be considered read-only, but the docs don't explicitly state that).
All of these actually relate to the selection of the Windows SDK version, but that is not the same as the minimum Windows version required at run time. The minimum Windows version at run time is actually controlled by the `_WIN32_WINNT` compiler definition (and `WINVER` for much older SDKs). You can build with a very recent SDK, but have the minimum deployment version set to something quite old. The only way that the SDK version relates to the minimum deployment version is that if you require a fairly recent deployment version, then the SDK you use has to know about it.
Unfortunately, apart from the inconsistencies in the naming between the above variables and properties (`..._MIN_VERSION` and `..._VERSION_MAXIMUM`), those names incorrectly imply that they control or relate to the target platform version, not the SDK version. The description of each one contains at least some degree of misleading comments, except for the `CMP0149` policy docs. This would be somewhat disruptive to fix. It would require new names that more accurately reflect what the properties and variables do, the new properties would need to take precedence over the old ones, and the old ones should be deprecated but still kept around for a long time. I don't know if a policy would be needed, or could even be used for this.https://gitlab.kitware.com/cmake/cmake/-/issues/25165file(GET_RUNTIME_DEPENDENCIES) can not resolve soft links on Windows2023-08-09T03:35:49-04:00DyatlovsGlowingRadSuitfile(GET_RUNTIME_DEPENDENCIES) can not resolve soft links on WindowsWe have attempted to resolve dependencies by creating soft links instead of copying them next to the executables.
In the process we have experienced that the solution worked fine in the build directory but during install, we received the...We have attempted to resolve dependencies by creating soft links instead of copying them next to the executables.
In the process we have experienced that the solution worked fine in the build directory but during install, we received the following error:
```
CMake Error at build/cmake_install.cmake:123 (file):
file INSTALL cannot find
"\??\C:\temp\playground\thirdparties\bin\some_function.dll": No error
```
You'll find an example project in the attachments [playground.zip](/uploads/d865b32fac598715629bc8237f541f76/playground.zip) and the main CmakeLists.txt is provided below:
```
cmake_minimum_required(VERSION 3.25)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
project(DUMMY_PROJECT VERSION 1.0.0 DESCRIPTION "Demonstrate symlinks on Windows" LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
add_subdirectory("modules")
add_executable(DummyMain main.cpp)
target_link_libraries(DummyMain PUBLIC dummy_lib PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/lib/some_function.lib")
target_include_directories(DummyMain PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/include")
# In this section only soft-links are created for dlls instead of copying them
# aside the executables
add_custom_command(TARGET DummyMain POST_BUILD
COMMAND ${CMAKE_COMMAND} -D OBJECT_DEPENDENCY_LIST="$<TARGET_RUNTIME_DLLS:DummyMain>" -D TARGET_DIR_FOR_DEP=$<TARGET_FILE_DIR:DummyMain> -P "${CMAKE_CURRENT_SOURCE_DIR}/cmake/soft_linker.cmake"
COMMENT "Running soft linker script for project dependencies"
COMMAND_EXPAND_LISTS
)
add_custom_command(TARGET DummyMain POST_BUILD
COMMAND ${CMAKE_COMMAND} -D OBJECT_DEPENDENCY_LIST="${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/bin/some_function.dll" -D TARGET_DIR_FOR_DEP=$<TARGET_FILE_DIR:DummyMain> -P "${CMAKE_CURRENT_SOURCE_DIR}/cmake/soft_linker.cmake"
COMMENT "Running soft linker script for precompiled dependencies"
COMMAND_EXPAND_LISTS
)
# This is the command that results in the following error:
# CMake Error at build/cmake_install.cmake:123 (file):
# file INSTALL cannot find
# "\??\C:\temp\playground\thirdparties\bin\some_function.dll": No error.
install(TARGETS DummyMain
RUNTIME_DEPENDENCIES
PRE_EXCLUDE_REGEXES "^api-ms-win.*" "^ext-ms.*
POST_EXCLUDE_REGEXES "^/lib.*" "[Ss][Yy][Ss][Tt][Ee][Mm]32.*"
RUNTIME DESTINATION "bin")
```https://gitlab.kitware.com/cmake/cmake/-/issues/24964Ninja: Support unconditional object path shortening on Windows2023-06-07T00:15:55-04:00Tristan LabelleNinja: Support unconditional object path shortening on WindowsI am running into a `MAX_PATH` issue on Windows where CMake is able to write under a substituted drive without needing to shorten the path, but later (after CMake) the same path is used in its full expanded form and exceeds `MAX_PATH`. I...I am running into a `MAX_PATH` issue on Windows where CMake is able to write under a substituted drive without needing to shorten the path, but later (after CMake) the same path is used in its full expanded form and exceeds `MAX_PATH`. It would help to have CMake unconditionally use shortened object paths.
The relevant code is around `cmLocalGenerator::GetObjectFileNameWithoutTarget`.
Related to: https://gitlab.kitware.com/cmake/cmake/-/issues/15859https://gitlab.kitware.com/cmake/cmake/-/issues/24842Winelib (winegcc/wineg++) support2023-04-23T23:43:12-04:00Mingye WangWinelib (winegcc/wineg++) supportI saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-i...I saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-include-link-info-or-compiler-wine-gnu-etc/6589) by Alex but noticed that it has no issue actually filed after @ben.boeckel's suggestion, so here it is.
As Alex mentioned, winegcc is about linking to Windows libs in native (non-Windows) executables, and the library search routine needs to adapt somewhat. Well, winegcc potentially links to native `.so` (and `.dylib`) too per https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/winegcc.c#L916. All the types it looks for is in [`guess_lib_type()`](https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/utils.c#L120).
https://bugs.winehq.org/show_bug.cgi?id=51793 is a related issue tracking this thing on the Wine side.https://gitlab.kitware.com/cmake/cmake/-/issues/24657CUDA/NVCC/Windows/Ninja: CUDA architecture flags break in response files2023-03-31T08:05:14-04:00LucasCUDA/NVCC/Windows/Ninja: CUDA architecture flags break in response filesHi,
I use CMake to compile CUDA accelerated code. I set the CUDA architectures according to the docs as
```
#...
set(CMAKE_CUDA_ARCHITECTURES 50 52 60 61 70 75 80 86)
#...
```
However on Windows nvcc throws the following error:
```
[1...Hi,
I use CMake to compile CUDA accelerated code. I set the CUDA architectures according to the docs as
```
#...
set(CMAKE_CUDA_ARCHITECTURES 50 52 60 61 70 75 80 86)
#...
```
However on Windows nvcc throws the following error:
```
[1/7] Building CUDA object CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj
FAILED: CMakeFiles/spline_psf_cu_impl.dir/src/spline_psf_gpu.cu.obj
C:\PROGRA~1\NVIDIA~2\CUDA\v11.7\bin\nvcc.exe -forward-unknown-to-host-compiler --options-file CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj.rsp -MD -MT CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj -MF CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj.d -x cu -rdc=true -c %SRC_DIR%\cpp_cuda_c\src\spline_psf_gpu.cu -o CMakeFiles\spline_psf_cu_impl.dir\src\spline_psf_gpu.cu.obj -Xcompiler=-FdCMakeFiles\spline_psf_cu_impl.dir\spline_psf_cu_impl.pdb,-FS
nvcc fatal : 'sm_52' is not in 'keyword=value' format
```
I believe this should be a CMake bug, no? The build on linux works fine.
You can take a look at the GH Action log
- [3_build__windows-2022__windows__powershell_.txt](/uploads/3d170ecc2bf43c393a1583d75adb7c1f/3_build__windows-2022__windows__powershell_.txt)
- [1_build__ubuntu-22.04__ubuntu__bash_-l__0__.txt](/uploads/979c4bd65cc96515e872095d2c2ff2c5/1_build__ubuntu-22.04__ubuntu__bash_-l__0__.txt)
or reproduce it with a fork of this
https://github.com/Haydnspass/SplinePSF/commit/0326f76e492b9aa54c8ff0088764da843d047257
Interestingly the status badge is still green even if the build fails.
PS: CMake also seems not too handle to long lines on windows, that's why I have to set https://github.com/Haydnspass/SplinePSF/blob/0326f76e492b9aa54c8ff0088764da843d047257/cpp_cuda_c/CMakeLists.txt#L73.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24622Dependencies for windows resource (.rc) files are not detected correctly2023-03-21T11:19:36-04:00Andrzej SzombierskiDependencies for windows resource (.rc) files are not detected correctlyCMake (at least with the Ninja back-end) scans only for #include-style dependencies in .rc files. When a binary file (such as an application icon) is compiled into a .res file, the build system doesn't know this, and doesn't regenerate t...CMake (at least with the Ninja back-end) scans only for #include-style dependencies in .rc files. When a binary file (such as an application icon) is compiled into a .res file, the build system doesn't know this, and doesn't regenerate the resource file when the dependency is updated.
Trivial example below:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.10)
project(example)
add_executable(example example.c example.rc)
```
example.c
```
int main(){return 0;}
```
example.rc
```
1 ICON DISCARDABLE "example.ico"
```
example.ico - use any icon file
How to reproduce:
```
$ cmake -G Ninja ..
[...]
-- Build files have been written to: C:/Users/ld/resourcebug/build
ld@w10vm VC ~/resourcebug/build
$ ninja
[1/3] Building C object CMakeFiles\example.dir\example.c.obj
[2/3] 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.
[3/3] Linking C executable example.exe
ld@w10vm VC ~/resourcebug/build
$ touch ../example.ico
ld@w10vm VC ~/resourcebug/build
$ ninja
ninja: no work to do.
```
Expected result: the executable is rebuilt with the updated iconhttps://gitlab.kitware.com/cmake/cmake/-/issues/24611Clang 16 on Windows for C++20 modules2023-03-21T08:58:47-04:00huangqinjinClang 16 on Windows for C++20 modules### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.ex...### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.exe -format=p1689 -- C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -x c++ C:/Users/huangqinjin/Projects/cxxmodules/named-module/hello.cppm -c -o named-module\CMakeFiles\named-module.dir\hello.cppm.obj -MT named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi -MD -MF named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi.d > named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi
error: no such file or directory: '>'
error: no such file or directory: 'named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi'
```
The stdout redirection cannot be used here.
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.0/Modules/Compiler/Clang-CXX.cmake#L42
### Issue 2 (After bypass issue 1)
Generated a strange BMI file `named-moduleCMakeFilesnamed-module.dirhello.pcm` in cmake binary dir.
The conetent of the response file `named-module\CMakeFiles\named-module.dir\hello.cppm.obj.modmap` is
```
-x c++-module
-fmodule-output=named-module\CMakeFiles\named-module.dir\hello.pcm
```
Seems to me that clang does not support back slash.
### Issue 3
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -MD -MT named-module/CMakeFiles/named-module.dir/main.cpp.obj -MF named-module\CMakeFiles\named-module.dir\main.cpp.obj.d @named-module\CMakeFiles\named-module.dir\main.cpp.obj.modmap -o named-module/CMakeFiles/named-module.dir/main.cpp.obj -c C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp
C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp:1:8: fatal error: module 'hello' not found
```
After investigation, clang C++20 module only supports `-std=c++20`, `-std=gnu++20` is not supported currently. So
`set(CMAKE_CXX_EXTENSIONS OFF)` is required.3.26.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24511Windows: Create import library from .def file and no sources2023-02-21T02:07:52-05:00Leonid PospelovWindows: Create import library from .def file and no sourcesCMake does not currently model something like `add_library(foo SHARED foo.def)`, with no other sources, to produce a `.lib` import library on Windows without running a linker to produce the corresponding `.dll` or `.exe` file.
<details>...CMake does not currently model something like `add_library(foo SHARED foo.def)`, with no other sources, to produce a `.lib` import library on Windows without running a linker to produce the corresponding `.dll` or `.exe` file.
<details><summary>Original Description</summary>
I have a project that builds `node.lib` with custom .def file (my compiler is MSVC)
```cmake
project(nodelib)
add_custom_target(nodelib_def ALL
COMMAND ${NODEJS_EXECUTABLE} ${CMAKE_SOURCE_DIR}/generateNodeLibDef.js
COMMENT "Generating .def file"
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
)
add_custom_target(nodelib ALL
COMMAND ${CMAKE_AR}
/def:${CMAKE_SOURCE_DIR}/node.def
/out:${CMAKE_BINARY_DIR}/node.lib
${CMAKE_STATIC_LINKER_FLAGS}
DEPENDS ${CMAKE_JS_NODELIB_DEF}
COMMENT "Building node.lib"
)
add_dependencies(nodelib nodelib_def)
install(FILES ${CMAKE_BINARY_DIR}/node.lib DESTINATION lib)
```
I'm trying to rewrite `add_custom_target` with `add_library`:
```cmake
add_library(node STATIC)
set_target_properties(node PROPERTIES LINK_FLAGS "/def:${CMAKE_SOURCE_DIR}/node.def")
```
I'm getting the following error:
```
CMake Error at C:/projects/vcpkg/scripts/buildsystems/vcpkg.cmake:623 (_add_library):
No SOURCES given to target: node
Call Stack (most recent call first):
CMakeLists.txt:10 (add_library)
CMake Generate step failed. Build files cannot be regenerated correctly.
ninja: build stopped: subcommand failed.
```
Can I somehow use `add_library`? Maybe there is something I'm missing
</details>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/24343cmake-gui: does not adapt to dark mode on Windows2023-09-08T09:17:26-04:00Alexandre Baroncmake-gui: does not adapt to dark mode on WindowsI'm working with CMake 3.25.1 on Windows 10.
The OS theme is set on Dark mode systemwide, but CMake has still has its default grey and white theme.
I wonder why is that?
It seems to me that CMake should reflect the system theme, if I re...I'm working with CMake 3.25.1 on Windows 10.
The OS theme is set on Dark mode systemwide, but CMake has still has its default grey and white theme.
I wonder why is that?
It seems to me that CMake should reflect the system theme, if I refer to another issue opened 3 years ago : [dark mode for CMake GUI](https://gitlab.kitware.com/cmake/cmake/-/issues/19869).
It was closed 2 years ago, because it was supposedly fixed.
Is it a known issue? Or am I missing something?https://gitlab.kitware.com/cmake/cmake/-/issues/24342Support building for Windows using 'onecore' libraires instead of legacy kern...2023-01-29T21:37:34-05:00Chuck WalbournSupport building for Windows using 'onecore' libraires instead of legacy kernel32.libThe current "Windows-MSVC.cmake" has logic for picking various combinations of default system libraires. For `WINDOWS_STORE` it uses the umbrella library "WindowsApp.lib", for (now legacy) `WINDOWS_PHONE` it uses "WindowsPhone.lib", and ...The current "Windows-MSVC.cmake" has logic for picking various combinations of default system libraires. For `WINDOWS_STORE` it uses the umbrella library "WindowsApp.lib", for (now legacy) `WINDOWS_PHONE` it uses "WindowsPhone.lib", and otherwise it uses various combinations of "kernel32.lib".
This allows projects to easily target classic Windows desktop and UWP, but makes it challenging to target "OneCore" variants like Windows 10 only, Xbox One, and Xbox Series X|S. The main issue here is that for those platforms, they have other umbrella libraries but removing kernel32.lib from the link is essential for correctness.
VS 2022 Update 2 added the ability to provide a specific property `CoreLibrariesDependencies` which allows a project to set its own core libraries specifically to address the scenario. For example, setting it to 'onecore_apiset.lib' or 'onecore.lib'.
Doing this with CMake in a systematic way is challenging, so I'm looking for a better solution.
While adding an entirely new target is one solution, another suggestion would be to have a specific CMake variable that could be used like `CoreLibrariesDependencies` to override the logic for selecting default libraries. Perhaps a `MSVC_CORE_LIBARIES` variable which if set overrides all the logic for `CMAKE_C_STANDARD_LIBRARIES_INIT`.
A few test cases:
* Build a DLL / EXE using only "onecore_apiset.lib". Due to some quirks of the Visual C/C++ CRT, this may also require `/NODEFAULTLIB:kernel32.lib` and `/NODEFAULTLIB:onecore.lib`. When you use 'dumpbin /imports` on the resulting EXE or DLL should *not* have any direct references to KERNEL32.DLL and everything will reference API set DLLs.
* Build a DLL / EXE using only "onecore.lib". This will still have a KERNEL32.DLL reference, but will have most things bound to an API set instead.
* Build a DLL / EXE using only "onecore_downlevel.lib".