CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2021-07-21T11:33:46-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/22450message: color output on Windows2021-07-21T11:33:46-04:00Brad Kingmessage: color output on Windows!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be neede...!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be needed to print color output on Windows while also preserving LF newlines and console encoding conversion.https://gitlab.kitware.com/cmake/cmake/-/issues/22442generate_export_header in project with C and CXX languages always goes CXX2021-07-19T22:18:31-04:00Samuel Marksgenerate_export_header in project with C and CXX languages always goes CXXI have a project with C and CXX.
```cmake
project(pp VERSION 0.0.0 LANGUAGES C CXX)
```
I'm careful to make all the headers .h and fully C compatible (with `` and all). Even guarding them with:
```c
#ifdef __cplusplus
extern "C" {
#endi...I have a project with C and CXX.
```cmake
project(pp VERSION 0.0.0 LANGUAGES C CXX)
```
I'm careful to make all the headers .h and fully C compatible (with `` and all). Even guarding them with:
```c
#ifdef __cplusplus
extern "C" {
#endif
```
But the newly C-compatible [`generate_export_header`](https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html) always generates CXX headers even when the target has this explicitly:
```cmake
set_target_properties("${LIBRARY_NAME}" PROPERTIES LINKER_LANGUAGE C)
```
Only just realised that my linker issues [MSVC only: undefined extern] are from an incorrectly generated export header.
For now I'll commit a generated header to version-control and use that on MSVC, but if you could fix this on CMake's end that would be great. Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/22441CPack/NSIS: "Invalid escape sequence \P" Windows paths2021-07-26T11:01:05-04:00Samuel MarksCPack/NSIS: "Invalid escape sequence \P" Windows pathsGiven `-DMYINSTALLPATH="C:\Program Files\foo"` then I get an error above invalid escape sequences at CPackConfig.cmake:33. So I:
`file(TO_CMAKE_PATH ${MYINSTALLPATH} MYINSTALLPATH)`
Then in NSIS64 generator (CPack) it doesn't let me pre...Given `-DMYINSTALLPATH="C:\Program Files\foo"` then I get an error above invalid escape sequences at CPackConfig.cmake:33. So I:
`file(TO_CMAKE_PATH ${MYINSTALLPATH} MYINSTALLPATH)`
Then in NSIS64 generator (CPack) it doesn't let me press "Next" because the slashes are in the wrong direction. So I:
`string(REPLACE "/" "\\" MYINSTALLPATH "${MYINSTALLPATH}")`; which brings me back to the original error. I'm running 3.21.0 (with that minimum version required).
EDIT: This worked. But I'm guessing it's not the right solution
```cmake
if (WIN32)
string(REPLACE "/" "\\\\" MYINSTALLPATH "${MYINSTALLPATH}")
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/224313.21 feature `install(TARGETS … RUNTIME_DEPENDENCIES)` Could not resolve file...2021-07-16T09:30:24-04:00Samuel Marks3.21 feature `install(TARGETS … RUNTIME_DEPENDENCIES)` Could not resolve file api-ms-win-core-apiquery-l1-1-0.dllCould not resolve file api-ms-win-core-apiquery-l1-1-0.dll
Replicate by changing `cmake_minimum_required(VERSION 3.21)` and adding `install(TARGETS "${LIBRARY_NAME}" RUNTIME_DEPENDENCIES)` to https://github.com/SamuelMarks/cmake-example...Could not resolve file api-ms-win-core-apiquery-l1-1-0.dll
Replicate by changing `cmake_minimum_required(VERSION 3.21)` and adding `install(TARGETS "${LIBRARY_NAME}" RUNTIME_DEPENDENCIES)` to https://github.com/SamuelMarks/cmake-example-with-vcpkg/blob/5ffcde4/versions/CMakeLists.txt#L77 and running through the whole `cmake ..`, `cmake --build .` and `cpack -G WIX -C Debug` dance.
As per https://answers.microsoft.com/en-us/windows/forum/all/missing-api-ms-win-core-dlls/d99d1368-0f92-43db-bbdb-7d080f1f96e9
> They're part of architectural changes to Windows to support multiple devices and system architectures. They shouldn't be used or linked to directly and should not themselves be distributed. Rather apps and programs should make use of MinCore.lib or MinCore_Downlevel.lib.
So really it should be added to your blacklist or transformed into the dependency it should be rather than this indirect artificial onehttps://gitlab.kitware.com/cmake/cmake/-/issues/22236clang-cl 7.0.0 invalid option '/notify_update'2021-05-25T09:41:16-04:00emptyVoidclang-cl 7.0.0 invalid option '/notify_update'Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 wi...Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - failed
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe - broken
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
[cmake] The C compiler
[cmake]
[cmake] "C:/Program Files (x86)/something/something/clang-cl.exe"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: D:/Projects/test/build/CMakeFiles/CMakeTmp
[cmake]
[cmake] Run Build Command(s):C:/PROGRA~2/something/Ninja/ninja.exe cmTC_8c4ed && [1/2] Building C object CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj
[cmake] [2/2] Linking C executable cmTC_8c4ed.exe
[cmake] FAILED: cmTC_8c4ed.exe
[cmake] cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_8c4ed.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\rc.exe --mt=C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\BUILDT~1\VC\Tools\MSVC\1416~1.270\bin\Hostx86\x86\link.exe /nologo CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj /out:cmTC_8c4ed.exe /implib:cmTC_8c4ed.lib /pdb:cmTC_8c4ed.pdb /version:0.0 /machine:X86 /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 ."
[cmake] MT: command "C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe /nologo /manifest CMakeFiles\cmTC_8c4ed.dir/intermediate.manifest /out:CMakeFiles\cmTC_8c4ed.dir/embed.manifest /notify_update" failed (exit code 0x1) with the following output:
[cmake] llvm-mt: error: invalid option '/notify_update'
[cmake] ninja: build stopped: subcommand failed.
```https://gitlab.kitware.com/cmake/cmake/-/issues/21973Ninja Multi-Config: custom commands with long command lines fail2021-03-26T09:23:28-04:00Alex Reinkingareinkin@qti.qualcomm.comNinja Multi-Config: custom commands with long command lines failI believe this has been going on for a while, but Ninja Multi-Config even as of CMake 3.20 is unable to successfully compile Halide.
Here are repro steps on Windows using vcpkg to manage dependencies. This happens inside an "x64 Native ...I believe this has been going on for a while, but Ninja Multi-Config even as of CMake 3.20 is unable to successfully compile Halide.
Here are repro steps on Windows using vcpkg to manage dependencies. This happens inside an "x64 Native Tools Command Prompt for VS 2019"
```
D:\>cmake --version
cmake version 3.20.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).
D:\>ninja --version
1.10.2
D:\vcpkg> vcpkg install libpng:x64-windows libjpeg-turbo:x64-windows llvm[target-all]:x64-windows
```
This step will likely take a long time because LLVM is slow to build.
```
D:\> git clone https://github.com/halide/Halide.git
D:\> cmake -G "Ninja Multi-Config" -S Halide -B Halide\build -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake
D:\> cmake --build Halide\build --config Release
...
[1908/4290] Generating included_schedule_file.runtime.obj
FAILED: src/autoschedulers/adams2019/included_schedule_file.runtime.obj
src\autoschedulers\adams2019\CMakeFiles\included_schedule_file.runtime.obj-51b089f.bat 19f43066e9a3772e
The system cannot find the file specified
Batch file failed at line 3 with errorcode 1
[1909/4290] Generating demo.runtime.obj
FAILED: src/autoschedulers/adams2019/demo.runtime.obj
src\autoschedulers\adams2019\CMakeFiles\demo.runtime.obj-f96ccee.bat 009edd0500709949
The system cannot find the file specified
Batch file failed at line 3 with errorcode 1
[1929/4290] Linking CXX executable bin\Release\buffer_copy.generator.exe
ninja: build stopped: subcommand failed.
```
This works perfectly well with the "Visual Studio 16 2019" generator with `-A x64 -Thost=x64`.
The batch file `src\autoschedulers\adams2019\CMakeFiles\demo.runtime.obj-f96ccee.bat` has the following contents:
```
@echo off
cd /D D:\Halide\build\src\autoschedulers\adams2019 || (set FAIL_LINE=2& goto :ABORT)
"C:\Program Files\CMake\bin\cmake.exe" -E env "PATH=D:\Halide\build\bin\RelWithDebInfo;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\\Extensions\Microsoft\IntelliCode\CLI;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\devinit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.2\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.2\libnvvp;C:\Program Files\Python39\Scripts;C:\Program Files\Python39;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\libnvvp;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files\Microsoft MPI\Bin;C:\Program Files\PuTTY;C:\Program Files\dotnet;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\doxygen\bin;C:\Program Files\MATLAB\R2020b\runtime\win64;C:\Program Files\MATLAB\R2020b\bin;C:\Program Files\Wolfram Research\WolframScript;C:\Program Files\Microsoft VS Code\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\dotnet;C:\Program Files\Git\cmd;C:\Program Files\NVIDIA Corporation\Nsight Compute 2020.3.0;C:\Program Files\nodejs;C:\Ruby30-x64\bin;C:\Users\Alex Reinking\AppData\Roaming\local\bin;C:\Users\Alex Reinking\AppData\Local\Microsoft\WindowsApps;C:\Users\Alex Reinking\AppData\Local\atom\bin;C:\Users\Alex Reinking\.dotnet\tools;C:\Users\Alex Reinking\AppData\Roaming\npm;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\x64\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\Linux\bin\ConnectionManagerExe" D:/Halide/build/bin/RelWithDebInfo/demo.generator.exe -r demo.runtime -o . -e object target=x86-64-windows || (set FAIL_LINE=3& goto :ABORT)
goto :EOF
:ABORT
set ERROR_CODE=%ERRORLEVEL%
echo Batch file failed at line %FAIL_LINE% with errorcode %ERRORLEVEL%
exit /b %ERROR_CODE%
```
There's an erroneous reference on the first line to `D:\Halide\build\bin\RelWithDebInfo` and to `D:/Halide/build/bin/RelWithDebInfo/demo.generator.exe`. The chosen config was Release.Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/21914IPO support check fails if CUDA is specified before CXX in enabled languages ...2021-04-25T11:02:51-04:00Pasquale ColaianniIPO support check fails if CUDA is specified before CXX in enabled languages (on Windows, with Clang)[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA...[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA before CXX breaks the cache generation.
The attachment serves as an example project.
```cmake
cmake_minimum_required(VERSION 3.18)
# Platform: Windows
# Command: cmake -G Ninja -D CMAKE_CXX_COMPILER="clang++" <src path>
# It fails also with clang-cl
# It does not fail with MSVC
# project(TestProgram LANGUAGES CXX CUDA) # this works
project(TestProgram LANGUAGES CUDA CXX) # this does not
include(CheckIPOSupported)
check_ipo_supported(RESULT result OUTPUT output LANGUAGES CXX)
if(result)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)
message(STATUS "Interprocedural Optimization is ON for CXX")
else()
message(SEND_ERROR "IPO is not supported: ${output}")
endif()
add_library(lib STATIC lib.cpp)
add_executable(test_program main.cpp)
target_link_libraries(test_program PRIVATE lib)
```
<details><summary>_CMakeError.log_</summary>
```
CXX compiler IPO check failed with the following output:
Change Dir: D:/test_ipo_windows_clang_cuda_cxx/build/CMakeFiles/_CMakeLTOTest-CXX/bin
Run Build Command(s):D:/PROGRA~1/Ninja/ninja.exe && [1/4] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
[2/4] Building CXX object CMakeFiles\boo.dir\main.cpp.obj
[3/4] Linking CXX static library foo.lib
FAILED: foo.lib
cmd.exe /C "cd . && D:\PROGRA~1\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\lib.exe /machine:x64 /out:foo.lib CMakeFiles\foo.dir\foo.cpp.obj && cd ."
Microsoft (R) Library Manager Version 14.28.29336.0
Copyright (C) Microsoft Corporation. All rights reserved.
CMakeFiles\foo.dir\foo.cpp.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0xBEC
ninja: build stopped: subcommand failed.
```
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/21905VS: Custom MSVC toolchain investigation2021-03-12T16:22:48-05:00Ghost UserVS: Custom MSVC toolchain investigationWe have a custom MSVC toolchain. However, we were getting an issue related to RC files. That only manifested on Ninja dirty builds.
```
# Here is how the bug will manifest itself:
# "ninja: error: FindFirstFileExA(note: including file: ...We have a custom MSVC toolchain. However, we were getting an issue related to RC files. That only manifested on Ninja dirty builds.
```
# Here is how the bug will manifest itself:
# "ninja: error: FindFirstFileExA(note: including file: d:/foobar/ms_sdk/n20246/10/include/10.0.20246.0/shared): The filename, directory name, or volume label syntax is incorrect."
```
I've posted about the issue here on the discourse:
https://discourse.cmake.org/t/setting-cmake-lang-architecture-id-cmake-cl-showincludes-prefix-to-get-rc-files-working/2920/1
```cmake
cmake_minimum_required(VERSION 3.15)
set(DEVELOPMENT_KIT_ROOT "C:/foobar")
set(FOOBAR_MSVC_VERSION "14.24.28314")
set(FOOBAR_WINDOWS_VERSION "19041")
set(FOOBAR_ARCH "x64")
set(FOOBAR_TOOLSET "x64")
list(APPEND CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
DEVELOPMENT_KIT_ROOT
FOOBAR_MSVC_VERSION
FOOBAR_WINDOWS_VERSION
FOOBAR_ARCH
FOOBAR_TOOLSET
)
# Define the target system and version:
# Only set CMAKE_SYSTEM_NAME when it's different than the host system name.
# Otherwise CMAKE_CROSSCOMPILING will be set to true unneccessarily.
# Which can cause longer builds for developers in some situations.
# https://discourse.cmake.org/t/do-i-need-to-set-the-cmake-system-name-when-making-a-toolchain-file/2861
if (NOT (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") )
set(CMAKE_SYSTEM_NAME "Windows" CACHE INTERNAL "")
endif()
set(CMAKE_SYSTEM_VERSION "10.0.${FOOBAR_WINDOWS_VERSION}.0" CACHE INTERNAL "")
if(FOOBAR_ARCH STREQUAL "x64")
set(CMAKE_SYSTEM_PROCESSOR AMD64)
elseif(FOOBAR_ARCH STREQUAL "x86")
set(CMAKE_SYSTEM_PROCESSOR x86)
else()
message(FATAL_ERROR "The only supported target architectures are x86 and x64!")
endif()
# Error check toolset
if (FOOBAR_TOOLSET STREQUAL "x64")
elseif (FOOBAR_TOOLSET STREQUAL "x86")
else()
message(FATAL_ERROR "The only supported toolsets are x64 and x86!")
endif()
# Setup FOOBAR DK directories
set(FOOBAR_MSVC_ROOT ${DEVELOPMENT_KIT_ROOT}/vc/${FOOBAR_MSVC_VERSION})
set(FOOBAR_MSVC_BIN_TOOLSET ${FOOBAR_MSVC_ROOT}/bin/Host${FOOBAR_TOOLSET}/${FOOBAR_ARCH})
set(FOOBAR_SDK_ROOT ${DEVELOPMENT_KIT_ROOT}/ms_sdk/n${FOOBAR_WINDOWS_VERSION}/10)
set(FOOBAR_SDK_BIN_TOOLSET ${FOOBAR_SDK_ROOT}/bin/10.0.${FOOBAR_WINDOWS_VERSION}.0/${FOOBAR_TOOLSET})
set(FOOBAR_SDK_LIB ${FOOBAR_SDK_ROOT}/lib/10.0.${FOOBAR_WINDOWS_VERSION}.0)
set(FOOBAR_SDK_INC ${FOOBAR_SDK_ROOT}/include/10.0.${FOOBAR_WINDOWS_VERSION}.0)
set(FOOBAR_WDK_ROOT ${DEVELOPMENT_KIT_ROOT}/ms_wdk/n${FOOBAR_WINDOWS_VERSION})
set(FOOBAR_WDK_LIB ${FOOBAR_WDK_ROOT}/lib/10.0.${FOOBAR_WINDOWS_VERSION}.0)
set(FOOBAR_WDK_INC ${FOOBAR_WDK_ROOT}/include/10.0.${FOOBAR_WINDOWS_VERSION}.0)
# Error checking
# I'm checking if the DEVELOPMENT_KIT_ROOT is defined as an absolute path
# because IS_DIRECTORY is only well defined if the path is absolute
# https://cmake.org/cmake/help/latest/command/if.html?highlight=is_directory#if
if ( IS_ABSOLUTE ${DEVELOPMENT_KIT_ROOT} )
set(FOOBAR_DK_DIRECTORIES_TO_ERROR_CHECK
${FOOBAR_MSVC_ROOT} ${FOOBAR_SDK_ROOT} ${FOOBAR_SDK_LIB}
${FOOBAR_SDK_INC} ${FOOBAR_WDK_ROOT} ${FOOBAR_WDK_LIB} ${FOOBAR_WDK_INC}
${FOOBAR_SDK_BIN_TOOLSET} ${FOOBAR_MSVC_BIN_TOOLSET}
)
# Make sure each directory exists
foreach(dir IN LISTS FOOBAR_DK_DIRECTORIES_TO_ERROR_CHECK)
if (NOT IS_DIRECTORY ${dir})
message(FATAL_ERROR "Include directory is not valid: ${dir}\n"
"Make sure to check your perforce mappings!\n")
endif()
endforeach()
endif()
# Cross Compiler
# In order to pass Visual Studio compiler identification we have to establish these variables
foreach(LANG C CXX)
set(CMAKE_${LANG}_COMPILER "${FOOBAR_MSVC_BIN_TOOLSET}/cl.exe" CACHE FILEPATH "")
set(CMAKE_${LANG}_COMPILER_ID "MSVC" CACHE STRING "")
# Extract the compiler version
execute_process(
# Execute cl.exe on the command line to extract the compiler version
COMMAND ${CMAKE_${LANG}_COMPILER}
# cl.exe outputs some of its output to standard error
# EX:
# Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27032.1 for x64
# Copyright (C) Microsoft Corporation. All rights reserved.
ERROR_VARIABLE cl_exe_ouput
# cl.exe outputs some of its output to standard output
# So just ignore this it isn't important
# EX:
# usage: cl [ option... ] filename... [ /link linkoption... ]
OUTPUT_QUIET
)
# Regex for the compiler version
string(REGEX MATCH ".* Version ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\).*" out ${cl_exe_ouput})
# If the regex fails then fatal error
if (NOT (${CMAKE_MATCH_COUNT} EQUAL "1"))
message(FATAL_ERROR "MSVC version regex failed")
endif()
# You have to set the compiler version
set(CMAKE_${LANG}_COMPILER_VERSION "${CMAKE_MATCH_1}" CACHE STRING "")
endforeach()
# This variable is neccessary to set for MSVC compilers greater than version 19.0 and greater
#
# Here is my attempt at an explanation (since there is no documentation online):
# VS2015 update 3 and above support language standard level flags, with the default and minimum level
# being C++14. This allows cmake to set variables/compiler-flags much more appropriately.
#
# To see the exact details see this module in your cmake implemenation.
# ...\share\cmake-3.16\Modules\Compiler\MSVC-CXX.cmake
#
# If that still doesn't make sense remove this check/set below
#
# To be honest although I know this logic below fixes the problem and is correct.
# It is still pretty hacky, and is a good argument to not use the DK in the future.
if (${CMAKE_CXX_COMPILER_VERSION} VERSION_GREATER "19.0")
set(CMAKE_CXX_STANDARD_COMPUTED_DEFAULT "14" CACHE INTERNAL "")
endif()
# Cross Tools
set(CMAKE_RC_COMPILER "${FOOBAR_SDK_BIN_TOOLSET}/rc.exe" CACHE FILEPATH "")
set(CMAKE_MT "${FOOBAR_SDK_BIN_TOOLSET}/mt.exe" CACHE FILEPATH "")
# Generator Tools
if (CMAKE_GENERATOR MATCHES "Visual Studio")
# MSVC_IDE doesn't seem to work in toolchains?
# https://discourse.cmake.org/t/cannot-use-msvc-ide-in-toolchain/2734
set(FOOBAR_MSVC_IDE ON)
endif()
if (FOOBAR_MSVC_IDE)
# Build with Multiple Processes, this is a nice quality of life for VS users
# This is the preferred way of speeding up vs builds.
# Also /MP option enables /FS by default.
set(genFlag "/MP")
else()
# If multiple CL.EXE write to the same .PDB file, please use /FS
# This ensures multi-threads builds like Ninja work properly
set(genFlag "/FS")
endif()
# Set the flags all projects will be forced to use.
# https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS_INIT.html
foreach(LANG C CXX)
set(CMAKE_${LANG}_FLAGS_INIT "${genFlag}")
endforeach()
set(FOOBAR_DK_INCLUDE_DIRECTORIES
"${FOOBAR_MSVC_ROOT}/include"
"${FOOBAR_SDK_INC}/ucrt"
"${FOOBAR_SDK_INC}/um"
"${FOOBAR_SDK_INC}/shared"
"${FOOBAR_WDK_INC}/km"
"${FOOBAR_WDK_INC}/um"
"${FOOBAR_WDK_INC}/shared"
)
set(FOOBAR_DK_LIBRARY_DIRECTORIES
"${FOOBAR_MSVC_ROOT}/lib/${FOOBAR_ARCH}"
"${FOOBAR_MSVC_ROOT}/atlmfc/lib/${FOOBAR_ARCH}"
"${FOOBAR_SDK_LIB}/ucrt/${FOOBAR_ARCH}"
"${FOOBAR_SDK_LIB}/um/${FOOBAR_ARCH}"
"${FOOBAR_WDK_LIB}/km/${FOOBAR_ARCH}"
"${FOOBAR_WDK_LIB}/um/${FOOBAR_ARCH}"
)
if (FOOBAR_MSVC_IDE)
string(REGEX MATCHALL "Visual Studio [0-9]+ ([0-9]+)" vsVersions ${CMAKE_GENERATOR})
set(vsYear ${CMAKE_MATCH_1})
if (${vsYear} VERSION_LESS "2010")
message(FATAL_ERROR "CMAKE_VS_SDK_*_DIRECTORIES require at least Visual Studio 2010")
endif()
# Set the appropriate binary directories
set(CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES "")
list(APPEND CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES ${FOOBAR_MSVC_BIN_TOOLSET})
list(APPEND CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES ${FOOBAR_SDK_BIN_TOOLSET})
# Don't allow MSVC defaults
set(CMAKE_VS_SDK_SOURCE_DIRECTORIES "")
set(CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES "")
set(CMAKE_VS_SDK_REFERENCE_DIRECTORIES "")
set(CMAKE_VS_SDK_EXCLUDE_DIRECTORIES "")
# Set include/library directories
set(CMAKE_VS_SDK_LIBRARY_DIRECTORIES ${FOOBAR_DK_LIBRARY_DIRECTORIES})
set(CMAKE_VS_SDK_INCLUDE_DIRECTORIES ${FOOBAR_DK_INCLUDE_DIRECTORIES})
# Platform Selection
# https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html#platform-selection
if ( ${vsYear} VERSION_GREATER_EQUAL "2019")
if(FOOBAR_ARCH STREQUAL "x64")
set(CMAKE_GENERATOR_PLATFORM "x64")
elseif(FOOBAR_ARCH STREQUAL "x86")
set(CMAKE_GENERATOR_PLATFORM "Win32")
else()
message(FATAL_ERROR "Unsupported platform ${FOOBAR_ARCH}")
endif()
endif()
# Toolset Selection
# https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html#toolset-selection
# host=<arch> specifies the host tools architecture as x64 or x86
#
# This is basically a quality of life to avoid cluttering the command line
set(CMAKE_GENERATOR_TOOLSET "host=${FOOBAR_TOOLSET}")
# Work Around:
# This command is only meaningful in the sense that it prevents Cmake from
# choosing a default toolset. 'FOOBAR_DK_TOOLSET' has no instrinsic value
# If you get rid of this, Visual Studio will still build correctly
# However, configuration will give weird output.
# It will list the default MSVC compiler instead of the one we chose.
set(CMAKE_VS_PLATFORM_TOOLSET_VERSION "FOOBAR_DK_TOOLSET")
else()
# Link Directories
foreach(TARGET EXE SHARED STATIC MODULE)
# W/A: CMake doesn't define CMAKE_<LANG>_STANDARD_LINK_DIRECTORIES.
# https://gitlab.kitware.com/cmake/cmake/issues/18222
set(CMAKE_${TARGET}_LINKER_FLAGS_INIT "")
foreach(dir IN LISTS FOOBAR_DK_LIBRARY_DIRECTORIES)
list(APPEND CMAKE_${TARGET}_LINKER_FLAGS_INIT
"/LIBPATH:${dir}"
)
endforeach()
# Neccessary for linker syntax
string(REPLACE ";" " " CMAKE_${TARGET}_LINKER_FLAGS_INIT "${CMAKE_${TARGET}_LINKER_FLAGS_INIT}")
endforeach()
# Include Directories
# NOTE: C/CXX make sense. The tricky one is RC. This is neccessary to support resource files.
foreach(LANG C CXX RC)
set(CMAKE_${LANG}_STANDARD_INCLUDE_DIRECTORIES ${FOOBAR_DK_INCLUDE_DIRECTORIES})
endforeach()
# This is neccessary to ensure RC files compile with our custom toolchain
# Otherwise dirty builds will break. This code basically patches a cmake bug.
#
# Here is the bug will manifest itself:
# "ninja: error: FindFirstFileExA(note: including file: d:/p4/DEVELOPMENT_KIT_ROOT/win/ms_sdk/n20246/10/include/10.0.20246.0/shared): The filename, directory name, or volume label syntax is incorrect."
if (CMAKE_GENERATOR MATCHES "Ninja")
# Compiling RC files needs to set this. The Ninja generator calls cmcldeps.exe to extract dependencies for RC
# files. But it configurates DepType to "gcc" so cmake cannot filter show includes prefix and the dependencies
# are stored in .ninja_deps with the prefix and cause next run of ninja to fail. The DepType cannot be forced
# to "msvc" otherwise the dependency changes won't trigger recompilation of RC files.
# The workaround is to set CMAKE_CL_SHOWINCLUDES_PREFIX to the exact English string "Note: including file: ".
# function CMAKE_DETERMINE_MSVC_SHOWINCLUDES_PREFIX may be used if any locale issue occurs.
set(CMAKE_CL_SHOWINCLUDES_PREFIX "Note: including file: " CACHE INTERNAL "FOOBAR WORKAROUND")
# The Ninja generator relies on the following variables to determine MSVC style PDB names. But these variables
# stored in cmake are only initialized to "" when it is first time run on a project before CMake${lang}Compiler
# .cmake are generated. The next run doesn't initilazed them because CMake${lang}Compiler.cmake are there. So
# they are null and SetMsvcTargetPdbVariable() returns false so ".dbg" suffix is used for PDBs.
# The workaround is to set them to either x64 or x86 (actually "" is enough).
#
# https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ARCHITECTURE_ID.html?highlight=architecture_id
set(CMAKE_CXX_ARCHITECTURE_ID ${FOOBAR_ARCH} CACHE INTERNAL "FOOBAR WORKAROUND")
set(CMAKE_C_ARCHITECTURE_ID ${FOOBAR_ARCH} CACHE INTERNAL "FOOBAR WORKAROUND")
endif()
endif()
# In conjunction with the variables below this makes all find_* commands
# only look in the DK
set(CMAKE_FIND_ROOT_PATH "${DEVELOPMENT_KIT_ROOT}")
# Make the find_file command only look in the DK
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
# Make the find_package command only look in the DK
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
# Make the find_library command only look in the DK
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
# Make the find_package command only look in the DK
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
```
I've done my best to sanitize my companies work and still providing a meaningful toolchain to the CMake team.
This toolchain is currently tested against Vs2019/Ninja. However it's only the Ninja path that is having problems.
So currently all 5 of these variables are necessary to compile our project with an MSVC toolchain.
```cmake
set(CMAKE_CXX_STANDARD_COMPUTED_DEFAULT "14" CACHE INTERNAL "")
set(CMAKE_C_STANDARD_COMPUTED_DEFAULT "90" CACHE INTERNAL "")
# These are necessary for RC files
set(CMAKE_CL_SHOWINCLUDES_PREFIX "Note: including file: " CACHE INTERNAL "FOOBAR WORKAROUND")
set(CMAKE_CXX_ARCHITECTURE_ID "x64" CACHE INTERNAL "FOOBAR WORKAROUND")
set(CMAKE_C_ARCHITECTURE_ID "x64" CACHE INTERNAL "FOOBAR WORKAROUND")
```
Should CMake toolchain authors be aware of these variables?https://gitlab.kitware.com/cmake/cmake/-/issues/21888VS: sequence of COMMANDS in add_custom_command not executing2021-03-05T09:41:41-05:00Brenton BostickVS: sequence of COMMANDS in add_custom_command not executing
Here is a minimal example of the problem. I have this CMakeLists.txt file:
```
cmake_minimum_required(VERSION 3.15)
project(trying-npm
LANGUAGES
NONE
)
set(PACKAGEJSON_STAMP ${PROJECT_BINARY_DIR}/package.json.stamp)
add_custom_c...
Here is a minimal example of the problem. I have this CMakeLists.txt file:
```
cmake_minimum_required(VERSION 3.15)
project(trying-npm
LANGUAGES
NONE
)
set(PACKAGEJSON_STAMP ${PROJECT_BINARY_DIR}/package.json.stamp)
add_custom_command(
OUTPUT
${PACKAGEJSON_STAMP}
COMMAND
${CMAKE_COMMAND} -E echo before
COMMAND
npm --version
COMMAND
${CMAKE_COMMAND} -E echo after
COMMAND
${CMAKE_COMMAND} -E touch ${PROJECT_BINARY_DIR}/package.json.stamp
DEPENDS
${PROJECT_SOURCE_DIR}/package.json
)
add_custom_target(vsix
ALL
DEPENDS
${PACKAGEJSON_STAMP}
)
```
The package.json file also exists but it can just be empty.
When I try to build, I see the before echo but I do not see the after echo.
Here is a transcript:
```
C:\dev\trying-npm\build>cmake --build .
CMake is re-running because C:/dev/trying-npm/build/CMakeFiles/generate.stamp is out-of-date.
the file 'C:/dev/trying-npm/CMakeLists.txt'
is newer than 'C:/dev/trying-npm/build/CMakeFiles/generate.stamp.depend'
result='-1'
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.19042.
-- Configuring done
-- Generating done
-- Build files have been written to: C:/dev/trying-npm/build
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Generating package.json.stamp
before
6.14.4
```
This is boiled down from an example of running `npm install` and generating a time stamp. This works fine on my Mac but fails on Windows.
I remove the npm command and then I can see the after echo.
npm --version has a 0 exit code and I cannot imagine what is happening to prevent the execution of subsequent commands.https://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/21816Ninja: Debug symbols in Fortran with Intel compiler on Windows2022-02-23T08:48:20-05:00Andreas SchulzNinja: Debug symbols in Fortran with Intel compiler on Windows**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Addi...**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Additional Information**
Apparently, during preprocessing of a source file with the Intel compiler the result is written to the terminal and then redirected into a subfolder. This behavior is defined in
CMAKE_Fortran_PREPROCESS_SOURCE (more precisely, here: -E > <PREPROCESSED_SOURCE>).
The preprocessed file contains a reference to the source file in the first line comment
(# 1 “…\main.f” in the minimal example),
which is used by the Intel compiler to create the reference in the object file. But since the preprocessed file is shifted into a subfolder, the relative path becomes outdated and in the object file we get an invalid path
(CMakeFiles\hello_world_fortran.dir…\main.f in the minimal example).
**Version Information**
The problem appears with Ninja version 1.9.0, CMake version 3.19.3, IFort version 19.1.1.216, and Fortran 77.https://gitlab.kitware.com/cmake/cmake/-/issues/21809SameFile() slows down install actions on Windows2021-02-15T11:26:44-05:00jalfdSameFile() slows down install actions on Windowsin `cmFileCopier::Install`, `SameFile()` is called as part of the up-to-date checks to determine if actually copying the file is necessary. The purpose of this seems to be an optimization, to avoid unnecessary file copies.
However, on W...in `cmFileCopier::Install`, `SameFile()` is called as part of the up-to-date checks to determine if actually copying the file is necessary. The purpose of this seems to be an optimization, to avoid unnecessary file copies.
However, on Windows, the `SameFile()` function is actually quite expensive, as it has to open both files with calls to `CreateFileW`.
Additionally, it is my understanding that the file will in practice always return false, as CMake would have to create a hard link during the install action for it to return true, and at least on Windows, it never does this.
Therefore, I would suggest that `cmFileCopier::Install` should only call `SameFile` on non-Windows platforms, where encountering hard links in the first place is actually feasible, and where checking whether the files are the same is much cheaper (just a `stat()` call, rather than having to open the files).
In my testing, I'm seeing a speedup for installs of around 30% just from removing this one call to `SameFile()`.https://gitlab.kitware.com/cmake/cmake/-/issues/21733Add a CPACK_NSIS_EXECUTABLE cpack var to be able to choose makensis.exe location2021-02-23T08:11:09-05:00Mathieu Westphal (Kitware)Add a CPACK_NSIS_EXECUTABLE cpack var to be able to choose makensis.exe locationSee here: https://discourse.cmake.org/t/how-to-select-nsis-on-a-non-standard-location/2570
Currently, to chooose NSIS location, modifying the PATH env var is needed, this is not practical.
According to this page, a patch already exist ...See here: https://discourse.cmake.org/t/how-to-select-nsis-on-a-non-standard-location/2570
Currently, to chooose NSIS location, modifying the PATH env var is needed, this is not practical.
According to this page, a patch already exist somewhere: https://wiki.vcmi.eu/How_to_build_VCMI_(Linux/Cmake/MXE)https://gitlab.kitware.com/cmake/cmake/-/issues/21657RFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOS2021-01-04T10:29:55-05:00Ben BoeckelRFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOSOn Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, s...On Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, so exclusions for that platform also make sense to provide.
See [this Discourse comment](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/7).
Cc: @kyle.edwards @ben.boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/21655FindMPI: not finding MSMPI's Fortran support2021-01-22T10:55:18-05:00Ben BoeckelFindMPI: not finding MSMPI's Fortran supportReported [on Discourse](https://discourse.cmake.org/t/the-findmpi-in-cmake-3-18-can-not-find-msmpi-for-fortran/1791). It is reported to have worked in 3.16.
Cc: @chuck.atkins @brad.kingReported [on Discourse](https://discourse.cmake.org/t/the-findmpi-in-cmake-3-18-can-not-find-msmpi-for-fortran/1791). It is reported to have worked in 3.16.
Cc: @chuck.atkins @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21638Generating import libraries without .dll, only through .def2023-03-29T03:09:38-04:00Clément GrégoireGenerating import libraries without .dll, only through .defI am trying to generate an import library for an external DLL that does not have one.
This means that I do not have the sources but only the `.def` file.
Is there a way to create an import library only in CMake ?
The linker command onl...I am trying to generate an import library for an external DLL that does not have one.
This means that I do not have the sources but only the `.def` file.
Is there a way to create an import library only in CMake ?
The linker command only needs to use `/DEF:` without any other inputs to work:
`lib /DEF:somelib.def /Out:somelib.lib /machine:x86`
I tried a few things but none seems to work:
- `SHARED` with no source file other than the `.def` will not invoke the linker, and thus not generate any `.lib` nor `.dll`
- `SHARED` with an empty `.cpp` source file will try to generate both `.lib` and `.dll`, which fails since symbols referenced by the `.def` do not exist
- `STATIC` with no source file other than the `.def` will not invoke the linker, and thus not generate any `.lib`
- `STATIC` with an empty `.cpp` source file will not invoke the linker, and thus not generate a `.lib` but the `.def` will not be used
I also tried setting `STATIC_LIBRARY_OPTIONS` (see below), but if you provide `.obj` files to the linker, it will not work as it will try to find functions referenced in the .def as if we were generating a `.dll`. And since the linker is not invoked without any `.cpp` file in the source list, well, I'm stuck.
```
set_target_properties(Fog PROPERTIES
LINKER_LANGUAGE CXX
STATIC_LIBRARY_OPTIONS "/DEF:${CMAKE_CURRENT_LIST_DIR}/definitions/Fog.${D2MOO_ORDINALS_VERSION}.def"
)
```
Is using a custom target + and `IMPORTED` cmake library the only thing I can use for this ?
Am I missing something ? I know it's pretty unusual to create an import library without also creating a .dll, is that something CMake should support out of the box ?https://gitlab.kitware.com/cmake/cmake/-/issues/21635CheckIPOSupported: Never detects LTO/IPO for Clang on Windows2021-01-10T15:55:25-05:00Sztergbaum RomanCheckIPOSupported: Never detects LTO/IPO for Clang on WindowsHello i'm trying the following code in my CMake:
```CMake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTER...Hello i'm trying the following code in my CMake:
```CMake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)
message(STATUS "We are in release - Successfully enabled IPO")
else ()
message(WARNING "IPO NOT SUPPORTED - Skipping reason: ${output}")
endif ()
endif ()
```
And i always get:
```
CMake Warning at CMakeLists.txt:63 (message):
IPO NOT SUPPORTED - Skipping reason: Change Dir:
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/bin
Run Build Command(s):C:/ProgramData/scoop/shims/ninja.exe && [1/4] Building
CXX object CMakeFiles/foo.dir/foo.cpp.obj
[2/4] Building CXX object CMakeFiles/boo.dir/main.cpp.obj
[3/4] Linking CXX static library foo.lib
[4/4] Linking CXX executable boo.exe
FAILED: boo.exe
cmd.exe /C "cd . && C:\ProgramData\scoop\shims\clang++.exe
-fuse-ld=lld-link -nostartfiles -nostdlib -g -Xclang -gcodeview -O0
-D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -flto
CMakeFiles/boo.dir/main.cpp.obj -o boo.exe -Xlinker /implib:boo.lib
-Xlinker /pdb:boo.pdb -Xlinker /version:0.0 foo.lib -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32
-ladvapi32 -loldnames && cmd.exe /C "cd /D
C:\Users\Public\Documents\atomicDEX-Desktop\cmake-build-release\CMakeFiles\_CMakeLTOTest-CXX\bin
&& C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile
-executionpolicy Bypass -file
C:/Users/Public/Documents/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/scripts/buildsystems/msbuild/applocal.ps1
-targetBinary
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/bin/boo.exe
-installedDir
C:/Users/Public/Documents/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/installed/x64-windows/debug/bin
-OutVariable out""
lld-link: error: undefined symbol: int __cdecl foo(void)
>>> referenced by
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/src/main.cpp
>>> CMakeFiles/boo.dir/main.cpp.obj
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.
```
Is there any reason ?
Compiler infos:
```
PS C:\Users\Public\Documents\atomicDEX-Desktop> clang --version
clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\ProgramData\scoop\apps\llvm\current\bin
```
CMake version: 3.19.2
full CMake to reproduce:
```CMake
cmake_minimum_required(VERSION 3.19.2)
project(cmake_lto)
set(CMAKE_CXX_STANDARD 20)
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)
message(STATUS "We are in release - Successfully enabled IPO")
else ()
message(WARNING "IPO NOT SUPPORTED - Skipping reason: ${output}")
endif ()
endif ()
add_executable(cmake_lto main.cpp)
```
Note: -flto=thin is not used even if it's available: https://clang.llvm.org/docs/ThinLTO.html
Usage on windows:
```
clang-cl -flto=thin -O2 -c file1.c file2.c
% lld-link /out:a.exe file1.obj file2.obj
```https://gitlab.kitware.com/cmake/cmake/-/issues/21536Pelles C toolchain support2020-12-01T12:39:59-05:00Charlie LinPelles C toolchain supportHas anyone added support for the toolchain here: http://www.smorgasbordet.com/pellesc/?
It claims full support for C99, C11, and C17, of which MSVC does not fully support these C versions.Has anyone added support for the toolchain here: http://www.smorgasbordet.com/pellesc/?
It claims full support for C99, C11, and C17, of which MSVC does not fully support these C versions.https://gitlab.kitware.com/cmake/cmake/-/issues/21532CMake doesn't find lld-link since 3.182020-12-14T11:16:39-05:00Harya LolipopCMake doesn't find lld-link since 3.18Compiler: llvm + clang-cl 9
Hi I'm using CMake and vcpkg and since a new update in vcpkg that bumped CMake from 3.17.2 to 3.18.4 I can't cross-compile for Windows on my Ubuntu builder.
```
[16/17] : && CMAKE_AR-NOTFOUND /machine:X86 /...Compiler: llvm + clang-cl 9
Hi I'm using CMake and vcpkg and since a new update in vcpkg that bumped CMake from 3.17.2 to 3.18.4 I can't cross-compile for Windows on my Ubuntu builder.
```
[16/17] : && CMAKE_AR-NOTFOUND /machine:X86 /nologo /out:zlib.lib CMakeFiles/zlib.dir/adler32.obj CMakeFiles/zlib.dir/compress.obj CMakeFiles/zlib.dir/crc32.obj CMakeFiles/zlib.dir/deflate.obj CMakeFiles/zlib.dir/gzclose.obj CMakeFiles/zlib.dir/gzlib.obj CMakeFiles/zlib.dir/gzread.obj CMakeFiles/zlib.dir/gzwrite.obj CMakeFiles/zlib.dir/inflate.obj CMakeFiles/zlib.dir/infback.obj CMakeFiles/zlib.dir/inftrees.obj CMakeFiles/zlib.dir/inffast.obj CMakeFiles/zlib.dir/trees.obj CMakeFiles/zlib.dir/uncompr.obj CMakeFiles/zlib.dir/zutil.obj && :
FAILED: zlib.lib
: && CMAKE_AR-NOTFOUND /machine:X86 /nologo /out:zlib.lib CMakeFiles/zlib.dir/adler32.obj CMakeFiles/zlib.dir/compress.obj CMakeFiles/zlib.dir/crc32.obj CMakeFiles/zlib.dir/deflate.obj CMakeFiles/zlib.dir/gzclose.obj CMakeFiles/zlib.dir/gzlib.obj CMakeFiles/zlib.dir/gzread.obj CMakeFiles/zlib.dir/gzwrite.obj CMakeFiles/zlib.dir/inflate.obj CMakeFiles/zlib.dir/infback.obj CMakeFiles/zlib.dir/inftrees.obj CMakeFiles/zlib.dir/inffast.obj CMakeFiles/zlib.dir/trees.obj CMakeFiles/zlib.dir/uncompr.obj CMakeFiles/zlib.dir/zutil.obj && :
/bin/sh: 1: CMAKE_AR-NOTFOUND: not found
ninja: build stopped: subcommand failed.
```
Using CMake version 3.17.2 works fine:
```
[16/17] : && /usr/bin/lld-link-9 /lib /machine:X86 /nologo /out:zlib.lib CMakeFiles/zlib.dir/adler32.obj CMakeFiles/zlib.dir/compress.obj CMakeFiles/zlib.dir/crc32.obj CMakeFiles/zlib.dir/deflate.obj CMakeFiles/zlib.dir/gzclose.obj CMakeFiles/zlib.dir/gzlib.obj CMakeFiles/zlib.dir/gzread.obj CMakeFiles/zlib.dir/gzwrite.obj CMakeFiles/zlib.dir/inflate.obj CMakeFiles/zlib.dir/infback.obj CMakeFiles/zlib.dir/inftrees.obj CMakeFiles/zlib.dir/inffast.obj CMakeFiles/zlib.dir/trees.obj CMakeFiles/zlib.dir/uncompr.obj CMakeFiles/zlib.dir/zutil.obj && :
[16/17] cd /vcpkg/buildtrees/zlib/x86-windows-nemirtingas-rel && /vcpkg/downloads/tools/cmake-3.17.2-linux/cmake-3.17.2-Linux-x86_64/bin/cmake -P cmake_install.cmake
```
I use this toolchain: https://github.com/Nemirtingas/clang-msvc-sdk
It also doesn't work on CMake 3.19.0 and 3.19.1.https://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,
Bogdan