CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2020-05-01T11:57:32-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/20525FindPython3 doesn't work under conda-build since CMake 3.17.02020-05-01T11:57:32-04:00Antoine PitrouFindPython3 doesn't work under conda-build since CMake 3.17.0This is a regression in CMake 3.17.0, it used to work in 3.16.*:
https://dev.azure.com/ursa-labs/crossbow/_build/results?buildId=9143&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181&l=695
In this ...This is a regression in CMake 3.17.0, it used to work in 3.16.*:
https://dev.azure.com/ursa-labs/crossbow/_build/results?buildId=9143&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181&l=695
In this build, it should have found the Python 3.6 interpreter installed in the build environment.3.16.6Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/20517$<CONFIG> evaluates to upper case string in target_link_libraries2020-04-10T09:22:25-04:00Daniel Eiband$<CONFIG> evaluates to upper case string in target_link_librariesUse the following CMakeLists.txt to reproduce:
```
cmake_minimum_required(VERSION 3.17)
project(Reproducer)
file(WRITE main.cxx "int main() { return 0; }")
add_executable(Reproducer main.cxx)
target_link_libraries(Reproducer PRIVATE...Use the following CMakeLists.txt to reproduce:
```
cmake_minimum_required(VERSION 3.17)
project(Reproducer)
file(WRITE main.cxx "int main() { return 0; }")
add_executable(Reproducer main.cxx)
target_link_libraries(Reproducer PRIVATE "$<CONFIG>-nonexisting")
```
In my case configured and built with:
```
cmake -G Ninja .
cmake --build .
```
The expected output is that the non-existing library cannot be found, for example with the Microsoft linker the output should be something like:
LINK : fatal error LNK1104: cannot open file 'Debug-nonexisting.lib'
The actual output of the CMakeLists.txt above is:
LINK : fatal error LNK1104: cannot open file 'DEBUG-nonexisting.lib'
The generator expression `$<CONFIG>` got expanded to `DEBUG` instead of `Debug`. When instead linking indirectly through usage requirements, then `$<CONFIG>` gets expanded to `Debug` as expected:
```
cmake_minimum_required(VERSION 3.17)
project(Reproducer)
file(WRITE lib.cxx "void dummy() { }")
add_library(Library lib.cxx)
target_link_libraries(Library PUBLIC "$<CONFIG>-nonexisting")
file(WRITE main.cxx "int main() { return 0; }")
add_executable(Reproducer main.cxx)
target_link_libraries(Reproducer PRIVATE Library)
```
As a results a generator expression `$<IN_LIST:$<CONFIG>,${list_of_configs}>` in `target_link_libraries` evaluates to `0` or `1` depending on the context where it is used.3.16.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20514CPack broken for Windows/NSIS for CMake 3.17.*: "ReserveFile /plugin" results...2020-04-01T10:43:31-04:00Jason ErbCPack broken for Windows/NSIS for CMake 3.17.*: "ReserveFile /plugin" results in script errorCPack is broken for Windows/NSIS for CMake 3.17+.
The error message in NSISOutput.log when attempting to build the "package" target using NSIS or NSIS64 generators:
```
Usage: ReserveFile [/nonfatal] [/r] [/x filespec [...]] file [file....CPack is broken for Windows/NSIS for CMake 3.17+.
The error message in NSISOutput.log when attempting to build the "package" target using NSIS or NSIS64 generators:
```
Usage: ReserveFile [/nonfatal] [/r] [/x filespec [...]] file [file...]
Error in script ".../_CPack_Packages/win64/NSIS/project.nsi" on line 633 -- aborting creation process
```
Line 633 in project.nsi is:
```
ReserveFile /plugin 'UserInfo.dll'
```
That line was added during [this change](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4171).
The problem affects 3.17.\*; 3.16 versions works correctly.
This issue was observed on Windows 10 x64.3.17.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20504CMake 3.17: ClangCL: No CMAKE_CXX_COMPILER could be found2020-04-07T06:59:39-04:00Petr DannhoferCMake 3.17: ClangCL: No CMAKE_CXX_COMPILER could be foundUsing CMake 3.17.0, generator fails with given output below. CMakeOutput.log gives 0 warnings and errors. CMake 3.16.5 works fine.
```
Env params:
set _GEN=Visual Studio 16 2019
set _ARCH=x64
set _TOOLSET=ClangCL
CMD: project("MI17_RO...Using CMake 3.17.0, generator fails with given output below. CMakeOutput.log gives 0 warnings and errors. CMake 3.16.5 works fine.
```
Env params:
set _GEN=Visual Studio 16 2019
set _ARCH=x64
set _TOOLSET=ClangCL
CMD: project("MI17_ROM" CXX)
/////////////////////////////////////////////////////////////////////////////////////////
-- The CXX compiler identification is Clang 10.0.0 with MSVC-like command-line
CMake Error at CMakeLists.txt:9 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "I:/dev/_bin/msvs16_x64_ClangCL/MI17_ROM/CMakeFiles/CMakeOutput.log".
CMAKEBUILD_ERROR: Configuration/generation failed.
/////////////////////////////////////////////////////////////////////////////////////////
```3.17.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20469cmake 3.17.0-rc3 double free or corruption2020-03-20T06:17:09-04:00SmartNet Clubcmake 3.17.0-rc3 double free or corruptioncmake version 3.17.0-rc3
<details>
<summary>Error in `/usr/bin/cmake': double free or corruption (!prev): 0x0000000001fefd60</summary>
```
-- *************************************************************************
The Crypto++ librar...cmake version 3.17.0-rc3
<details>
<summary>Error in `/usr/bin/cmake': double free or corruption (!prev): 0x0000000001fefd60</summary>
```
-- *************************************************************************
The Crypto++ library does not officially support CMake. CMake support is a
community effort, and the library works with the folks using CMake to help
improve it. If you find an issue then please fix it or report it at
https://github.com/noloader/cryptopp-cmake.
-- *************************************************************************
-- The C compiler identification is GNU 6.5.0
-- The CXX compiler identification is GNU 6.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- cryptopp BUILD_STATIC=ON
-- cryptopp BUILD_SHARED=ON
-- cryptopp BUILD_TESTING=OFF
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5")
-- OpenMP: TRUE
-- Performing Test CRYPTOPP_IA32_SSE2
-- Performing Test CRYPTOPP_IA32_SSE2 - Success
-- Performing Test CRYPTOPP_IA32_SSSE3
-- Performing Test CRYPTOPP_IA32_SSSE3 - Success
-- Performing Test CRYPTOPP_IA32_SSE41
-- Performing Test CRYPTOPP_IA32_SSE41 - Failed
-- Performing Test CRYPTOPP_IA32_SSE42
-- Performing Test CRYPTOPP_IA32_SSE42 - Success
-- Performing Test CRYPTOPP_IA32_CLMUL
-- Performing Test CRYPTOPP_IA32_CLMUL - Success
-- Performing Test CRYPTOPP_IA32_AES
-- Performing Test CRYPTOPP_IA32_AES - Success
-- Performing Test CRYPTOPP_IA32_AVX
-- Performing Test CRYPTOPP_IA32_AVX - Success
-- Performing Test CRYPTOPP_IA32_AVX2
-- Performing Test CRYPTOPP_IA32_AVX2 - Success
-- Performing Test CRYPTOPP_IA32_SHA
-- Performing Test CRYPTOPP_IA32_SHA - Success
-- Performing Test CRYPTOPP_MIXED_ASM
-- Performing Test CRYPTOPP_MIXED_ASM - Success
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Platform: x86_64
-- Native arch: FALSE
-- Compiler: /usr/bin/c++
-- Compiler options: -Wall -Wno-unused-variable -Werror -fno-strict-aliasing -fvisibility=hidden -Wall -Wno-unused-variable -Werror -fno-strict-aliasing -fvisibility=hidden -fopenmp -DCRYPTOPP_DISABLE_SSE4
-- Compiler definitions:
-- Build type: RELEASE
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
LINK_TYPE
RUNTIME_LINK_TYPE
-- Build files have been written to: /work/CRYPTOPP_8_2_0/build
*** Error in `/usr/bin/cmake': double free or corruption (!prev): 0x0000000001fefd60 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fe6b56db7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fe6b56e437a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fe6b56e853c]
/usr/bin/cmake[0x79fa8d]
/usr/bin/cmake[0x482464]
/usr/bin/cmake[0x77fd81]
/usr/bin/cmake[0x780bd9]
/usr/bin/cmake[0x624990]
/usr/bin/cmake[0x52d593]
/usr/bin/cmake[0x423892]
/usr/bin/cmake[0x417b79]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fe6b5684830]
/usr/bin/cmake[0x420379]
======= Memory map: ========
00400000-00c16000 r-xp 00000000 08:16 2506366 /usr/bin/cmake
00e16000-00e17000 r--p 00816000 08:16 2506366 /usr/bin/cmake
00e17000-00e1b000 rw-p 00817000 08:16 2506366 /usr/bin/cmake
00e1b000-00e26000 rw-p 00000000 00:00 0
01cbd000-020b4000 rw-p 00000000 00:00 0 [heap]
7fe6b0000000-7fe6b0021000 rw-p 00000000 00:00 0
7fe6b0021000-7fe6b4000000 ---p 00000000 00:00 0
7fe6b5664000-7fe6b5824000 r-xp 00000000 08:16 136229 /lib/x86_64-linux-gnu/libc-2.23.so
7fe6b5824000-7fe6b5a24000 ---p 001c0000 08:16 136229 /lib/x86_64-linux-gnu/libc-2.23.so
7fe6b5a24000-7fe6b5a28000 r--p 001c0000 08:16 136229 /lib/x86_64-linux-gnu/libc-2.23.so
7fe6b5a28000-7fe6b5a2a000 rw-p 001c4000 08:16 136229 /lib/x86_64-linux-gnu/libc-2.23.so
7fe6b5a2a000-7fe6b5a2e000 rw-p 00000000 00:00 0
7fe6b5a2e000-7fe6b5a45000 r-xp 00000000 08:16 131339 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe6b5a45000-7fe6b5c44000 ---p 00017000 08:16 131339 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe6b5c44000-7fe6b5c45000 r--p 00016000 08:16 131339 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe6b5c45000-7fe6b5c46000 rw-p 00017000 08:16 131339 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fe6b5c46000-7fe6b5d4e000 r-xp 00000000 08:16 136299 /lib/x86_64-linux-gnu/libm-2.23.so
7fe6b5d4e000-7fe6b5f4d000 ---p 00108000 08:16 136299 /lib/x86_64-linux-gnu/libm-2.23.so
7fe6b5f4d000-7fe6b5f4e000 r--p 00107000 08:16 136299 /lib/x86_64-linux-gnu/libm-2.23.so
7fe6b5f4e000-7fe6b5f4f000 rw-p 00108000 08:16 136299 /lib/x86_64-linux-gnu/libm-2.23.so
7fe6b5f4f000-7fe6b6122000 r-xp 00000000 08:16 2498781 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fe6b6122000-7fe6b6321000 ---p 001d3000 08:16 2498781 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fe6b6321000-7fe6b632c000 r--p 001d2000 08:16 2498781 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fe6b632c000-7fe6b632f000 rw-p 001dd000 08:16 2498781 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fe6b632f000-7fe6b6332000 rw-p 00000000 00:00 0
7fe6b6332000-7fe6b634a000 r-xp 00000000 08:16 136375 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fe6b634a000-7fe6b6549000 ---p 00018000 08:16 136375 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fe6b6549000-7fe6b654a000 r--p 00017000 08:16 136375 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fe6b654a000-7fe6b654b000 rw-p 00018000 08:16 136375 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fe6b654b000-7fe6b654f000 rw-p 00000000 00:00 0
7fe6b654f000-7fe6b6556000 r-xp 00000000 08:16 136383 /lib/x86_64-linux-gnu/librt-2.23.so
7fe6b6556000-7fe6b6755000 ---p 00007000 08:16 136383 /lib/x86_64-linux-gnu/librt-2.23.so
7fe6b6755000-7fe6b6756000 r--p 00006000 08:16 136383 /lib/x86_64-linux-gnu/librt-2.23.so
7fe6b6756000-7fe6b6757000 rw-p 00007000 08:16 136383 /lib/x86_64-linux-gnu/librt-2.23.so
7fe6b6757000-7fe6b675a000 r-xp 00000000 08:16 136253 /lib/x86_64-linux-gnu/libdl-2.23.so
7fe6b675a000-7fe6b6959000 ---p 00003000 08:16 136253 /lib/x86_64-linux-gnu/libdl-2.23.so
7fe6b6959000-7fe6b695a000 r--p 00002000 08:16 136253 /lib/x86_64-linux-gnu/libdl-2.23.so
7fe6b695a000-7fe6b695b000 rw-p 00003000 08:16 136253 /lib/x86_64-linux-gnu/libdl-2.23.so
7fe6b695b000-7fe6b6b76000 r-xp 00000000 08:16 136133 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7fe6b6b76000-7fe6b6d75000 ---p 0021b000 08:16 136133 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7fe6b6d75000-7fe6b6d91000 r--p 0021a000 08:16 136133 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7fe6b6d91000-7fe6b6d9d000 rw-p 00236000 08:16 136133 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7fe6b6d9d000-7fe6b6da0000 rw-p 00000000 00:00 0
7fe6b6da0000-7fe6b6dfe000 r-xp 00000000 08:16 136135 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7fe6b6dfe000-7fe6b6ffe000 ---p 0005e000 08:16 136135 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7fe6b6ffe000-7fe6b7002000 r--p 0005e000 08:16 136135 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7fe6b7002000-7fe6b7009000 rw-p 00062000 08:16 136135 /lib/x86_64-linux-gnu/libssl.so.1.0.0
7fe6b7009000-7fe6b702f000 r-xp 00000000 08:16 136201 /lib/x86_64-linux-gnu/ld-2.23.so
7fe6b71fc000-7fe6b7204000 rw-p 00000000 00:00 0
7fe6b722d000-7fe6b722e000 rw-p 00000000 00:00 0
7fe6b722e000-7fe6b722f000 r--p 00025000 08:16 136201 /lib/x86_64-linux-gnu/ld-2.23.so
7fe6b722f000-7fe6b7230000 rw-p 00026000 08:16 136201 /lib/x86_64-linux-gnu/ld-2.23.so
7fe6b7230000-7fe6b7231000 rw-p 00000000 00:00 0
7ffce3809000-7ffce382e000 rw-p 00000000 00:00 0 [stack]
7ffce3952000-7ffce3955000 r--p 00000000 00:00 0 [vvar]
7ffce3955000-7ffce3957000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
```
</details>3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20465Cmake 3.17.0 rc3 cannot find Python 3.82020-03-18T07:54:29-04:00Vitaly ZaitsevCmake 3.17.0 rc3 cannot find Python 3.8Cmake 3.17.0 rc3 cannot find Python 3.8:
```
BUILDSTDERR: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
BUILDSTDERR: Could NOT find Python (missing: Python_EXECUTABLE Interpreter)
BUIL...Cmake 3.17.0 rc3 cannot find Python 3.8:
```
BUILDSTDERR: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
BUILDSTDERR: Could NOT find Python (missing: Python_EXECUTABLE Interpreter)
BUILDSTDERR: Call Stack (most recent call first):
BUILDSTDERR: /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
BUILDSTDERR: /usr/share/cmake/Modules/FindPython.cmake:358 (find_package_handle_standard_args)
BUILDSTDERR: Telegram/cmake/generate_scheme.cmake:8 (find_package)
BUILDSTDERR: Telegram/cmake/lib_scheme.cmake:18 (generate_scheme)
BUILDSTDERR: Telegram/CMakeLists.txt:35 (include)
-- Configuring incomplete, errors occurred!
```
Cmake version: 3.17.0-0.4.rc3.fc33
Python version: 3.8.2-2.fc33
OS: Fedora Rawhide (F33)
Steps to reproduce:
```
find_package(Python REQUIRED)
```3.17.0Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/20414llvm-rc: The compilation flags are wrongly forwared2020-03-04T08:19:36-05:00Thomas Bernardllvm-rc: The compilation flags are wrongly forwaredThe compilation flags which are not understood by llvm-rc are forwarded through the `<FLAGS>` expansion.
The defines are supposed to be forwared in case some leftover from the pre-processing step are to be expanded.The compilation flags which are not understood by llvm-rc are forwarded through the `<FLAGS>` expansion.
The defines are supposed to be forwared in case some leftover from the pre-processing step are to be expanded.3.17.0https://gitlab.kitware.com/cmake/cmake/-/issues/20349Unable to build documentation using Sphinx on Ubuntu 16.042020-02-12T15:04:55-05:00Kyle EdwardsUnable to build documentation using Sphinx on Ubuntu 16.04When attempting to prepare the 3.17.0-rc1 release for Ubuntu, I got the following error:
```console
$ ninja documentation
FAILED: cd /root/cmake/build/Utilities/Sphinx && /usr/bin/sphinx-build -c /root/cmake/build/Utilities/Sphinx -d /r...When attempting to prepare the 3.17.0-rc1 release for Ubuntu, I got the following error:
```console
$ ninja documentation
FAILED: cd /root/cmake/build/Utilities/Sphinx && /usr/bin/sphinx-build -c /root/cmake/build/Utilities/Sphinx -d /root/cmake/build/Utilities/Sphinx/doctrees -b html /root/cmake/src/Help /root/cmake/build/Utilities/Sphinx/html > build-html.log
Encoding error:
'ascii' codec can't decode byte 0xe2 in position 6453: ordinal not in range(128)
The full traceback has been saved in /tmp/sphinx-err-_7x_gyxn.log, if you want to report the issue to the developers.
```
The log file contained the following:
```console
$ cat /tmp/sphinx-err-_7x_gyxn.log
# Sphinx version: 1.3.6
# Python version: 3.5.2 (CPython)
# Docutils version: 0.12 release
# Jinja2 version: 2.8
# Last messages:
# reading sources... [ 11%] generator/Visual Studio 15 2017
# reading sources... [ 11%] generator/Visual Studio 16 2019
# reading sources... [ 11%] generator/Visual Studio 6
# reading sources... [ 11%] generator/Visual Studio 7
# reading sources... [ 11%] generator/Visual Studio 7 .NET 2003
# reading sources... [ 11%] generator/Visual Studio 8 2005
# reading sources... [ 11%] generator/Visual Studio 9 2008
# reading sources... [ 11%] generator/Watcom WMake
# reading sources... [ 11%] generator/Xcode
# reading sources... [ 12%] guide/tutorial/index
# Loaded extensions:
# alabaster (0.7.7) from /usr/lib/python3/dist-packages/alabaster/__init__.py
# cmake (unknown version) from /root/cmake/src/Utilities/Sphinx/cmake.py
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/cmdline.py", line 244, in main
app.build(opts.force_all, filenames)
File "/usr/lib/python3/dist-packages/sphinx/application.py", line 267, in build
self.builder.build_update()
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 251, in build_update
'out of date' % len(to_build))
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 265, in build
self.doctreedir, self.app))
File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 547, in update
self._read_serial(docnames, app)
File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 567, in _read_serial
self.read_doc(docname, app)
File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 720, in read_doc
pub.publish()
File "/usr/lib/python3/dist-packages/docutils/core.py", line 218, in publish
self.apply_transforms()
File "/usr/lib/python3/dist-packages/docutils/core.py", line 199, in apply_transforms
self.document.transformer.apply_transforms()
File "/usr/lib/python3/dist-packages/docutils/transforms/__init__.py", line 171, in apply_transforms
transform.apply(**kwargs)
File "/root/cmake/src/Utilities/Sphinx/cmake.py", line 258, in apply
title = self.parse_title(env.docname)
File "/root/cmake/src/Utilities/Sphinx/cmake.py", line 241, in parse_title
for line in f:
File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 6453: ordinal not in range(128)
```3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20338FindMPI: Regression when re-running on existing build tree2020-02-11T08:17:59-05:00Brad KingFindMPI: Regression when re-running on existing build treeThe change in !4153 only works on the first run in a build tree. After that, the cache entries we save have different parts of the original list of include directories split up as before. On runs after the first one, we now have two pr...The change in !4153 only works on the first run in a build tree. After that, the cache entries we save have different parts of the original list of include directories split up as before. On runs after the first one, we now have two problems:
* The original list is not re-assembled into `MPI_<LANG>_INCLUDE_DIRS` anymore.
* The cache entries we save for `MPI_<LANG>_HEADER_DIR`, `MPI_<LANG>_ADDITIONAL_INCLUDE_DIRS`, etc. no longer preserve the order so we do not have enough information to re-assemble them.3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20326install: change in PUBLIC_HEADER handling between 3.13.5 and 3.14.02020-02-12T09:10:02-05:00Victor Bombiinstall: change in PUBLIC_HEADER handling between 3.13.5 and 3.14.0Hi,
Using this cmake file https://github.com/sonoro1234/LuaJIT-libsndfile/blob/0b03b48ff76615d2f9f6dab7491c76679f511a88/CMakeLists.txt
I am geting this error (not happening in 3.13.5)
```
[100%] Built target sndfile_ffi
Install the pro...Hi,
Using this cmake file https://github.com/sonoro1234/LuaJIT-libsndfile/blob/0b03b48ff76615d2f9f6dab7491c76679f511a88/CMakeLists.txt
I am geting this error (not happening in 3.13.5)
```
[100%] Built target sndfile_ffi
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: c:/anima2/sndfile.dll
CMake Error at cmake_install.cmake:54 (file):
file cannot create directory: C:/Program Files
(x86)/libsndfile_ffi/include. Maybe need administrative privileges.
```
previously (with v3.13.5) it was:
```
[100%] Built target sndfile_ffi
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: c:/anima2/sndfile.dll
-- Installing: c:/anima2/samplerate.dll
-- Installing: c:/anima2/lua/sndfile_ffi.lua
-- Installing: c:/anima2/lua/samplerate.lua
```
Thanks3.16.5Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20322CMake 3.16 orders of magnitude slower in the Generate phase for Makefiles com...2020-02-11T09:37:50-05:00Viktor KirilovCMake 3.16 orders of magnitude slower in the Generate phase for Makefiles compared to older versionsI'm consulting a company on how to speed up their builds and I immediately pointed them to precompiled headers and unity builds - the 10 minute full build could easily drop to 2-3 minutes. Luckily CMake 3.16 was recently released and [it...I'm consulting a company on how to speed up their builds and I immediately pointed them to precompiled headers and unity builds - the 10 minute full build could easily drop to 2-3 minutes. Luckily CMake 3.16 was recently released and [it supports both of those](https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-16/), so I told them to upgrade.
The problem is the following: once they switched from CMake 2.6 to 3.16 the time it took to run CMake jumped from about 20 seconds to more than 10 minutes. Most of the time is spent in the generate phase. It does complete successfully if you gave it enough time and the code compiled successfully with unity builds, but this CMake time is unacceptable.
Here is their setup:
- CMake 2.6, old style CMake with global flags/defines/includes - not modern (target-based). Nothing too fancy - no custom commands or build rules & complicated dependencies.
- the compiler used is GCC 7 and they generate Makefiles - the OS is CentOS 7, Kernel: Linux 3.10.0-862.14.4.el7.x86_64
- around 2000 ```.cpp``` files spread across 100 libraries and 600 executables (most of which are test executables with a single ```.cpp``` in them)
- most ```.cpp``` files are gathered/globbed with [```aux_source_directory```](https://cmake.org/cmake/help/latest/command/aux_source_directory.html) - we know not explicitly listing the ```.cpp``` files is an anti-pattern, but that's besides the point - I think this is irrelevant since this should happen in the configuration step and not during the generation, correct?
Here is what we observed:
- we did a binary search through the different CMake versions and concluded that the huge slowdown happened between 3.15 and 3.16 - exactly when the precompiled header and unity build support was added, but I don't think those features have anything to do with the slowdown - I can't think of a reason for them to have such an impact - it must be some other refactoring or change...
- we disabled all tests (that means almost all 600 executables were removed) - slimming down the number of CMake targets from 700 to a bit more than 100 - and the time it took to run CMake dropped significantly, but was still a couple of times longer than with CMake 2.6 for all the 700 targets.
- we observed what was happening using ```strace``` and there were mostly ```lstat``` and ```access``` calls along with some reads and writes - but this was endless - seemed like hundreds of operations per second in a very repeatable manner. Also there was constantly an attempt to find ```libgflags.so``` which was constantly failing. Unfortunately I don't have such logs right now.
- we did a callgrind profile and here is what it looks like after a couple of minutes of running: https://i.imgur.com/Z9AObso.png (the callgrind output file can be found [here](https://gist.githubusercontent.com/onqtam/3d0a606d827cb286c9a20b686ea435f5/raw/50d3c45c729fc7a7dc588309d1c1a75fab4b234f/callgrind-slow-cmake)) - seems like most of the time is spent in ```ComputeLinkLibs()``` and getting the full name and definitions of targets and whatnot... Is having 700 targets too much? Is this a quadratic or exponential problem? Why isn't it an issue with CMake 3.15?
I couldn't find any reports of anyone else having the same problem on the internet... Any ideas what to try next? Perhaps profile using Perf? Try with Ninja as a backend ([report of that being faster](https://stackoverflow.com/questions/26701628/cmake-is-slow-to-generate-makefiles#comment58568390_26701628))?3.16.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20291FindBLAS failing with Intel Parallel Studio2021-02-14T11:17:12-05:00Jakub BendaFindBLAS failing with Intel Parallel StudioThe changes introduced in commit 6bd9cee63885f1a2029faf0756c1dd4277cf7766 (merge request https://gitlab.kitware.com/cmake/cmake/merge_requests/4246) seem to break compatibility of *FindBLAS* with Intel MKL provided by the Intel compiler ...The changes introduced in commit 6bd9cee63885f1a2029faf0756c1dd4277cf7766 (merge request https://gitlab.kitware.com/cmake/cmake/merge_requests/4246) seem to break compatibility of *FindBLAS* with Intel MKL provided by the Intel compiler suites in Linux. Tested with Intel Parallel Studio XE 2020 with the following script
```cmake
cmake_minimum_required(VERSION 3.16)
project(TestBlas)
find_package(BLAS)
```
and invocation
```cmake
cmake -D BLA_VENDOR=Intel10_64lp .
```
The library that is not being found is *libiomp5*.
### Background
While Intel Parallel Studio does set the environment variable `MKLROOT` to the subfolder containing MKL, this folder does not contain the compiler run-time libraries, of which at least *libiomp5* is needed with threaded MKL. Before the above-mentioned commit, the search directory with the needed thread library was added by means of `CMAKE_C_IMPLICIT_LINK_DIRECTORIES`, which is populated from the environment variable `LIBRARY_PATH` defined by the package. However, this seems now unintentionally broken.
Actually, there are two issues with *FindBLAS*, the first one new, the other existed even before. Both of them are related to specifics of the CMake language.
### Issue 1: Attempt to append to a macro argument
In the macro `CHECK_BLAS_LIBRARIES`, an attempt is made to append strings to the variable `_addlibdir`, which is a parameter of the macro. Whether this is documented somewhere in CMake or a bug, the APPEND action does not have any effect whatsoever. Only when I introduce a replacement local variable, say
```cmake
set(_addlibdirs ${_addlibdir})
```
and operate on that one, the following APPEND works. This is well reproducible with minimal script like this
```cmake
cmake_minimum_required(VERSION 3.16)
project(TestListAppend)
macro(my_macro param)
set(var ${param})
message("var before = ${var}")
message("param before = ${param}")
list(APPEND param "world")
list(APPEND var "world")
message("param after = ${param}")
message("var after = ${var}")
endmacro()
my_macro("Hello")
```
which prints
```
var before = Hello
param before = Hello
param after = Hello
var after = Hello;world
```
illustrating that while APPEND to a normal variable works well, it does not do anything when applied to macro parameter. If this is normal in CMake, then the macro `CHECK_BLAS_LIBRARIES` should be fixed accordingly.
### Issue 2: Environment variable fails to dereference [NO LONGER RELEVANT]
The script also tries to add the contents of `LD_LIBRARY_PATH` to the list of directories to be searched. However, even if the above point is solved, the result of the statement
```cmake
list(APPEND _addlibdir ENV LD_LIBRARY_PATH)
```
seems to be just addition of the literal string "ENV" and "LD_LIBRARY_PATH" to `_addlibdir`. Obviously, this is not the desired outcome. A minimal reproducible example would be
```cmake
cmake_minimum_required(VERSION 3.16)
project(TestENV)
set(mylist)
list(APPEND mylist ENV PATH)
message("${mylist}")
```
which simply prints
```
ENV;PATH
```
rather than the content of the environment variable `PATH`. If this is expected, I think that the non-functional code should not be there at all.3.17.0https://gitlab.kitware.com/cmake/cmake/-/issues/20254CPACK_COMPONENT_<COMPONENT>_DESCRIPTION being appended to2020-01-27T09:27:44-05:00Harry GeorgeCPACK_COMPONENT_<COMPONENT>_DESCRIPTION being appended toReproducer
```cmake
cmake_minimum_required(VERSION 3.16.3)
project(test)
set(CPACK_GENERATOR "DEB")
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "badger")
set(CPACK_COMPONENT_TEST_DESCRIPTION "My Description...Reproducer
```cmake
cmake_minimum_required(VERSION 3.16.3)
project(test)
set(CPACK_GENERATOR "DEB")
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "badger")
set(CPACK_COMPONENT_TEST_DESCRIPTION "My Description")
set(CPACK_COMPONENTS_ALL TEST)
include(CPack)
```
When running dpkg-deb -I I would expect to see
> Description: My Description
(and you do pre 3.16)
but I actually see
> Description: test built using CMake<p>
> My Description
This might be related to https://gitlab.kitware.com/cmake/cmake/issues/20102 but that has been closed and as far as I can tell in 3.16.3 which still has this new behaviour.
Old, incorrect reproducer:
```cmake
cmake_minimum_required(VERSION 3.16.3)
project(test)
set(CPACK_GENERATOR "DEB")
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "badger")
set(CPACK_DEBIAN_TEST_DESCRIPTION "My Description")
set(CPACK_COMPONENTS_ALL TEST)
include(CPack)
```3.16.4Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20234FindMPI: Regression in include dir logic when using MPI compiler wrappers2020-01-22T09:30:57-05:00Brad KingFindMPI: Regression in include dir logic when using MPI compiler wrappersThe change in !4153 converted a function to a macro, but that causes the `return()` call inside it to apply in the caller's context, which may return from the entire module. We either need to make it a function again or restructure the ...The change in !4153 converted a function to a macro, but that causes the `return()` call inside it to apply in the caller's context, which may return from the entire module. We either need to make it a function again or restructure the logic in the macro to put the condition around its entire content.3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20224FindOpenSSL.cmake strips library keyword information2020-01-17T09:25:29-05:00rFindOpenSSL.cmake strips library keyword informationHi,
when attempting to build mosquitto[1] with TLS support and CMake[2], when specifying the OpenSSL parameters from the command line[3] the resulting FindPackage(OpenSSL) invocation strips the 'debug' and 'optimized' keywords from the ...Hi,
when attempting to build mosquitto[1] with TLS support and CMake[2], when specifying the OpenSSL parameters from the command line[3] the resulting FindPackage(OpenSSL) invocation strips the 'debug' and 'optimized' keywords from the OPENSSL_LIBRARIES string, leading to an errorneously linked mosquitto.exe in debug buils[4]. This can be easily seen by adding something like `message(STATUS "OPENSSL_LIBRARIES ${OPENSSL_LIBRARIES}")` around line 418 in FindOpenSSL.cmake. The use of REMOVE_DUPLICATES here is clearly wrong, because the duplicate 'debug' and 'optimized' values in the list are required for a correct build.
[1] https://mosquitto.org/files/source/mosquitto-1.6.8.tar.gz
[2] CMake Version 3.16.1
[3] `cmake -S mosquitto-1.6.8/ -Bbld -DLIB_EAY_DEBUG=openssl/lib_nt/libeay32_vc141_x86_dbg.lib -DLIB_EAY_RELEASE=openssl/lib_nt/libeay32_vc141_x86.lib -DSSL_EAY_DEBUG=openssl/lib_nt/ssleay32_vc141_x86_dbg.lib -DSSL_EAY_RELEASE=openssl/lib_nt/ssleay32_vc141_x86.lib -DOPENSSL_INCLUDE_DIR=openssl/include`
[4] ![wronglink](/uploads/af9176295014573bb9fdcaf5d349bc52/wronglink.PNG)3.16.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20194add_custom_command: regression in DEPENDS on relative path2020-01-20T11:52:05-05:00Brad Kingadd_custom_command: regression in DEPENDS on relative pathThe change in !4148 broke this case:
```console
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(CustomDepend NONE)
add_custom_command(
OUTPUT out.txt
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR...The change in !4148 broke this case:
```console
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(CustomDepend NONE)
add_custom_command(
OUTPUT out.txt
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/in/in.txt out.txt
DEPENDS in/in.txt
VERBATIM
)
add_custom_target(drive ALL DEPENDS out.txt)
$ cmake .. -GNinja
...
$ ninja
...
ninja: error: 'in/in.txt', needed by 'out.txt', missing and no known rule to make it
```3.17.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/20182CMake >= 3.15 Fails to compile C++ executables when CUDA is enabled and CMAKE...2020-02-04T10:40:48-05:00Alexander KorsunskyCMake >= 3.15 Fails to compile C++ executables when CUDA is enabled and CMAKE_CUDA_SEPARABLE_COMPILATION is ONPlease consider the following project:
CMakeLists.txt:
```cmake
project(SeparableCompCPPOnly LANGUAGES CXX CUDA)
set(CMAKE_CUDA_SEPARABLE_COMPILATION ON)
add_executable(helloworld main.cpp)
```
main.cpp:
```cpp
#include <iostream>
int ...Please consider the following project:
CMakeLists.txt:
```cmake
project(SeparableCompCPPOnly LANGUAGES CXX CUDA)
set(CMAKE_CUDA_SEPARABLE_COMPILATION ON)
add_executable(helloworld main.cpp)
```
main.cpp:
```cpp
#include <iostream>
int main() { std::cout << "Helloworld!\n"; return 0; }
```
With CMake 3.14, this project compiles. With CMake 3.15 and newer, compilation fails:
```
Scanning dependencies of target helloworld
[ 33%] Building CXX object CMakeFiles/helloworld.dir/main.cpp.o
[ 66%] Linking CUDA device code CMakeFiles/helloworld.dir/cmake_device_link.o
[100%] Linking CXX executable helloworld
/opt/RCPE/gcc/8.3.0/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/helloworld.dir/cmake_device_link.o: in function `__cudaUnregisterBinaryUtil':
link.stub:(.text+0xf): undefined reference to `__cudaUnregisterFatBinary'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/helloworld.dir/build.make:103: helloworld] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/helloworld.dir/all] Fehler 2
make: *** [Makefile:84: all] Fehler 2
```
It seems that CMake >= 3.15 tries to unconditionally do a device link, even if no CUDA code is involved. My guess is that either !3320 or !3491 is involved, but that is for you to decide.
In case you are wondering why I would enable the CUDA language and CMAKE_CUDA_SEPARABLE_COMPILATION if I don't even have CUDA sources:
This is just a minimal reproduction example. My real project has multiple CUDA targets and multiple C++-only targets and I had CMAKE_CUDA_SEPARABLE_COMPILATION set to on globally, to not have to set it individually on all CUDA targets (see issue #7478). This worked in 3.14 and lower, but broke in 3.15.3.15.7Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/20168EXCLUDE_FROM_ALL directory property at top level no longer works since CMake ...2021-05-24T11:56:00-04:00Craig ScottEXCLUDE_FROM_ALL directory property at top level no longer works since CMake 3.15.4The following minimal project can be used to demonstrate that the `EXCLUDE_FROM_ALL` directory property no longer has any effect if set in the top level directory, starting with the CMake 3.15.4 release:
*CMakeLists.txt*
```cmake
cmake_...The following minimal project can be used to demonstrate that the `EXCLUDE_FROM_ALL` directory property no longer has any effect if set in the top level directory, starting with the CMake 3.15.4 release:
*CMakeLists.txt*
```cmake
cmake_minimum_required(VERSION 3.14)
project(dirPropRegression)
set_directory_properties(PROPERTIES EXCLUDE_FROM_ALL YES)
add_subdirectory(child)
```
*child/CMakeLists.txt*
```cmake
add_executable(subapp main.cpp) # Contents of main.cpp are just int main() { return 0; }
```
Building this project without specifying a target should result in the "all" target being built, which in turn should build nothing. With CMake 3.15.4 or later, it still builds the `subapp` target, even though the `child` directory has been excluded from the all target. The likely culprit is !3863 which was also back-ported to CMake 3.14.7, which also shows the regression (3.14.6 is fine and so is 3.15.0).
A brief scan of the tests also suggests that we don't have any test cases that cover the `EXCLUDE_FROM_ALL` directory property.https://gitlab.kitware.com/cmake/cmake/-/issues/20102CPACK_DEBIAN_PACKAGE_DESCRIPTION does not respect documentation2020-01-23T04:52:09-05:00DamienCPACK_DEBIAN_PACKAGE_DESCRIPTION does not respect documentationSince https://gitlab.kitware.com/cmake/cmake/merge_requests/3541, according to `CPACK_DEBIAN_PACKAGE_DESCRIPTION` documentation `CPACK_PACKAGE_DESCRIPTION_SUMMARY` should be used as description if none of the following variables is set:
...Since https://gitlab.kitware.com/cmake/cmake/merge_requests/3541, according to `CPACK_DEBIAN_PACKAGE_DESCRIPTION` documentation `CPACK_PACKAGE_DESCRIPTION_SUMMARY` should be used as description if none of the following variables is set:
- CPACK_DEBIAN_\<COMPONENT>_DESCRIPTION
- CPACK_DEBIAN_PACKAGE_DESCRIPTION
- CPACK_COMPONENT_\<compName>_DESCRIPTION
- CPACK_PACKAGE_DESCRIPTION
- CPACK_PACKAGE_DESCRIPTION_FILE
Steps to reproduce:
```cmake
cmake_minimum_required(VERSION 3.16)
project(foo LANGUAGES NONE)
set(CPACK_GENERATOR DEB)
set(CPACK_PACKAGE_CONTACT "foo@bar.com")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Summary of package should be used as description")
include(CPack)
```
```bash
mkdir build && cd build && cmake ..
cmake --build . --target package
```
The output `dpkg --info foo-0.1.1-Linux.deb` is:
```
[...]
Description: Summary of package should be used as description
DESCRIPTION
===========
.
This is an installer created using CPack (https://cmake.org). No additional installation instructions provided.
.
.
[...]
```
It means that `CPACK_PACKAGE_DESCRIPTION_FILE` is read even if the variable was not explicitly set.3.16.3Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20101AUTOMOC: processing .hh files can break existing projects2019-12-19T09:52:39-05:00Brad KingAUTOMOC: processing .hh files can break existing projectsAmong the problems reported in #20081 is that the [OpenMesh](https://graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh) `OpenMesh-8.0` branch does not build with CMake 3.16.0 (or 3.16.1). I bisected the problem down to commit 4a9154537c12e...Among the problems reported in #20081 is that the [OpenMesh](https://graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh) `OpenMesh-8.0` branch does not build with CMake 3.16.0 (or 3.16.1). I bisected the problem down to commit 4a9154537c12e5f47e71018a7d485530a376c6da from !3511 for #13904. The problem is caused by handling `.hh` files with AUTOMOC where we didn't before.3.16.2Brad KingBrad King