CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2021-03-25T16:58:42-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/21985CUDAToolkit ignores CUDAToolkit_ROOT if another nvcc is in PATH2021-03-25T16:58:42-04:00Aurelien BouteillerCUDAToolkit ignores CUDAToolkit_ROOT if another nvcc is in PATHHere is a trace output from the configuration of my project
```
cmake . -DCUDAToolkit_ROOT=/some/dir
cmake-3.18.2-xm7dwpxesxzgm3ovhglyg4zqerh2lw6s/cmake-3.18/Modules/FindCUDAToolkit.cmake(511): find_program(CUDAToolkit_NVCC_EXECUTABLE...Here is a trace output from the configuration of my project
```
cmake . -DCUDAToolkit_ROOT=/some/dir
cmake-3.18.2-xm7dwpxesxzgm3ovhglyg4zqerh2lw6s/cmake-3.18/Modules/FindCUDAToolkit.cmake(511): find_program(CUDAToolkit_NVCC_EXECUTABLE NAMES nvcc nvcc.exe PATHS ENV CUDA_PATH PATH_SUFFIXES bin )
cmake-3.18.2-xm7dwpxesxzgm3ovhglyg4zqerh2lw6s/share/cmake-3.18/Modules/FindCUDAToolkit.cmake(518): if(NOT CUDAToolkit_NVCC_EXECUTABLE AND ( DEFINED CUDAToolkit_ROOT OR DEFINED ENV{CUDAToolkit_ROOT} ) )
```
The evaluation order of the expressions results in find_program picking `nvcc` from PATH, rather than abiding to the provided `CUDAToolkit_ROOT`. Then, the remainder of the detection logic will base itself upon the found `nvcc` and completely ignore the supplied parameter.
According to the documentation, this behavior is expected only when using `enable_language(CUDA)` which has not been performed in this project.https://gitlab.kitware.com/cmake/cmake/-/issues/21983Ninja Multi-Config produces invalid copy_idb_pdb.cmake scripts2021-11-09T07:53:23-05:00Alex Reinkingareinkin@qti.qualcomm.comNinja Multi-Config produces invalid copy_idb_pdb.cmake scriptsDiscovered while investigating #21973 -- building a Windows project with Ninja Multi-Config calls a generated `copy_idb_pdb.cmake` script during the build. I do not know CMake's internals well enough to find a minimal test case, sorry.
...Discovered while investigating #21973 -- building a Windows project with Ninja Multi-Config calls a generated `copy_idb_pdb.cmake` script during the build. I do not know CMake's internals well enough to find a minimal test case, sorry.
Here's what I _could_ find (quoting myself from the other issue):
> `void cmLocalGenerator::CopyPchCompilePdb` is broken in multiple places. The `configGenex` lambda tests to see if the generator is Visual Studio specifically rather than a multi-config generator when deciding whether or not to insert `$<CONFIG:...>`.
>
> The foreach loop in the generated `copy_idb_pdb.cmake` script is running out of its 30 retries (each of which take 1 second) and there's no code after the 30th retry to make the build fail with an internal error.
These are the code segments that seem to be the culprits:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0/Source/cmLocalGenerator.cxx#L2703-2724
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0/Source/cmLocalGenerator.cxx#L2729-2739Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/21980How to set PLANTUML_JAR_PATH2021-03-25T10:13:47-04:00Mateusz ManiaHow to set PLANTUML_JAR_PATHTo simplify example I have a **docs** directory with the following content:
* plantuml.jar
* CMakeLists.txt
* index.md with embedded PlantUML
CMakeLists.txt:
```cmake
set(PLANTUML_JAR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/plantuml.jar")
do...To simplify example I have a **docs** directory with the following content:
* plantuml.jar
* CMakeLists.txt
* index.md with embedded PlantUML
CMakeLists.txt:
```cmake
set(PLANTUML_JAR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/plantuml.jar")
doxygen_add_docs(docs
"${CMAKE_CURRENT_SOURCE_DIR}/index.md")
```
I run cmake, then **make docs** and get the following message:
```bash
docs/index.md:52: warning: ignoring \startuml command because PLANTUML_JAR_PATH is not set
```
CMake generated Doxyfile.docs:
```
PLANTUML_JAR_PATH =
PLANTUML_CFG_FILE =
PLANTUML_INCLUDE_PATH =
```
Documentation is generated but without PlantUML diagrams. What am I doing wrong?
U used cmake 3.16.3 and 3.19.3 on Ubuntu 20.04.2 LTS and CnetOS 8.3.2011 with the same result.https://gitlab.kitware.com/cmake/cmake/-/issues/21978parallel build is broken in 3.20.02021-06-09T08:24:52-04:00Mathieu Prevotparallel build is broken in 3.20.0I have a build command which starts like this `cmake -G $target -t v142, host=x64 -A x64 -j16 ` and it works well with 3.19.* but not with 3.20.0:
> CMake Error: Unknown argument -j16
> CMake Error: Run 'cmake --help' for all supported ...I have a build command which starts like this `cmake -G $target -t v142, host=x64 -A x64 -j16 ` and it works well with 3.19.* but not with 3.20.0:
> CMake Error: Unknown argument -j16
> CMake Error: Run 'cmake --help' for all supported options.https://gitlab.kitware.com/cmake/cmake/-/issues/21976[feature request] a cross platform find GNU GCC macro2021-03-25T10:17:01-04:00Foad[feature request] a cross platform find GNU GCC macroFollowing [this discussion](https://github.com/ElmerCSC/elmerfem/issues/199#issuecomment-804070759), we have the issue that we can't find the GNU GCC (gcc, g++, and gfortran) installed via HomeBrew on macOS. There might some temporary wo...Following [this discussion](https://github.com/ElmerCSC/elmerfem/issues/199#issuecomment-804070759), we have the issue that we can't find the GNU GCC (gcc, g++, and gfortran) installed via HomeBrew on macOS. There might some temporary workaround for this specific issue, but it would be great if we could have script/macro (e.g., `findGCC.cmake`) that would fine the GNU compilers automatically. Thanks for your kind support in advance.
**P.S.1.** I also posted this [here on CMake Discourse](https://discourse.cmake.org/t/feature-request-a-cross-platform-find-gnu-gcc-macro/3017).
**P.S.2.** I just created a [Discord channel for CMake](https://discord.gg/4RTrr7KvTG). Feel free to join if you like chat services.
**P.S.3.** I also posted this [here on Reddit](https://www.reddit.com/r/cmake/comments/mcukfm/feature_request_a_cross_platform_find_gnu_gcc/?utm_source=share&utm_medium=web2x&context=3) and there are some comment(s).https://gitlab.kitware.com/cmake/cmake/-/issues/21975Generator Expression in add_custom_command OUTPUT not working2021-03-25T00:57:58-04:00Andrii GorinGenerator Expression in add_custom_command OUTPUT not workingTried with version 3.20 on windows.
Code to reproduce:
```
# test 'add_custom_command(OUTPUT <...>)' generator expression
macro(add_custom_target_build
targetName
)
add_custom_command(
OUTPUT $<TARGET_PROPERTY:${target...Tried with version 3.20 on windows.
Code to reproduce:
```
# test 'add_custom_command(OUTPUT <...>)' generator expression
macro(add_custom_target_build
targetName
)
add_custom_command(
OUTPUT $<TARGET_PROPERTY:${targetName},property1>
COMMAND ${CMAKE_COMMAND}
ARGS -E touch $<TARGET_PROPERTY:${targetName},property1>
)
add_custom_target(build-${targetName}
DEPENDS $<TARGET_PROPERTY:${targetName},property1>
)
endmacro()
add_custom_target(target1)
set_target_properties(target1 PROPERTIES
property1 ${CMAKE_CURRENT_BINARY_DIR}/target1-property1-file.txt
)
add_custom_target_build(target1)
```
Error message:
```
Error evaluating generator expression:
$<TARGET_PROPERTY:target1,property1>
Target "target1" not found.
```https://gitlab.kitware.com/cmake/cmake/-/issues/21974CPack/RPM: Setting CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON breaks 'CPACK_RPM_<c...2021-04-14T15:37:42-04:00Greg MajszakCPack/RPM: Setting CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON breaks 'CPACK_RPM_<component>_PRE_INSTALL_SCRIPT_FILE'I have the following files:
CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.17.5)
project(main VERSION 1.0.0)
set(CMAKE_CXX_STANDARD 11)
add_executable(main main.cpp)
include(GNUInstallDirs)
# Install file README.txt to d...I have the following files:
CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.17.5)
project(main VERSION 1.0.0)
set(CMAKE_CXX_STANDARD 11)
add_executable(main main.cpp)
include(GNUInstallDirs)
# Install file README.txt to doc directory
install(FILES
${PROJECT_SOURCE_DIR}/README.txt
DESTINATION ${CMAKE_INSTALL_DOCDIR}
COMPONENT common)
set(CPACK_COMPONENTS_ALL common main)
set(CPACK_GENERATOR RPM)
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VERSION ${PACKAGE_VERSION})
set(CPACK_RPM_COMPONENT_INSTALL ON)
# Path to file containing common pre install script
set(CPACK_RPM_COMMON_PRE_INSTALL_SCRIPT_FILE ${PROJECT_SOURCE_DIR}/preCommon.bash)
# Path to file containing main pre install script
set(CPACK_RPM_MAIN_PRE_INSTALL_SCRIPT_FILE ${PROJECT_SOURCE_DIR}/preMain.bash)
set(CPACK_RPM_CONFIG_DEFAULT_GROUP ${PROJECT_NAME})
set(CPACK_RPM_CONFIG_DEFAULT_USER ${PROJECT_NAME})
# Enable generation of debuginfo RPM package(s)
set(CPACK_RPM_DEBUGINFO_PACKAGE ON)
# Create a single debuginfo package even if components packaging is set
# TODO - FIXME! Enabling this breaks 'CPACK_RPM_COMMON_PRE_INSTALL_SCRIPT_FILE', why?
#set(CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON)
set(CPACK_RPM_FILE_NAME RPM-DEFAULT)
set(CPACK_RPM_MAIN_COMPONENT ${PROJECT_NAME})
set(CPACK_RPM_PACKAGE_RELEASE 1)
set(CPACK_RPM_PACKAGE_RELEASE_DIST ON)
include(CPack)
```
main.cpp:
```cpp
#include <iostream>
int main()
{
std::cout << "Hello world!" << std::endl;
}
```
README.txt:
```
CMAKE(1) CMake CMAKE(1)
NAME
cmake - CMake Command-Line Reference
```
preCommon.bash
```bash
echo "Hello from common.rpm pre install script"
```
preMain.bash:
```bash
echo "Hello from main.rpm pre install script"
```
```console
$ cmake3 --version
cmake3 version 3.17.5
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
$ uname -r
3.10.0-1160.15.2.el7.x86_64
```
With `#set(CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON)` disabled, RPMs generate as expected:
```console
build]$ rm -rf * && cmake3 .. && make package && rpm -qp --scripts *.rpm
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
...
CPack3: - package: /.../CMakeCPackBug/build/main-1.0.0-1.el7.x86_64.rpm generated.
CPack3: - package: /.../CMakeCPackBug/build/main-common-1.0.0-1.el7.x86_64.rpm generated.
preinstall scriptlet (using /bin/sh):
echo "Hello from main.rpm pre install script"
postinstall program: /bin/sh
preuninstall program: /bin/sh
postuninstall program: /bin/sh
preinstall scriptlet (using /bin/sh):
echo "Hello from common.rpm pre install script"
postinstall program: /bin/sh
preuninstall program: /bin/sh
postuninstall program: /bin/sh
build]$
```
With `set(CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON)` enabled, RPMs generate omitted scriptlets for all non-CPACK_RPM_MAIN_COMPONENT components:
```console
build]$ rm -rf * && cmake3 .. && make package && rpm -qp --scripts *.rpm
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
...
CPack3: - package: /.../CMakeCPackBug/build/main-1.0.0-1.el7.x86_64.rpm generated.
CPack3: - package: /.../CMakeCPackBug/build/main-common-1.0.0-1.el7.x86_64.rpm generated.
preinstall scriptlet (using /bin/sh):
echo "Hello from main.rpm pre install script"
postinstall program: /bin/sh
preuninstall program: /bin/sh
postuninstall program: /bin/sh
build]$
```
Suspect related to [issue #21951](https://gitlab.kitware.com/cmake/cmake/-/issues/21951).Domen VrankarDomen Vrankarhttps://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/21972CMake 3.20 change of Linux binary names breaks CI / scripts2021-12-13T11:07:02-05:00Robert MaynardCMake 3.20 change of Linux binary names breaks CI / scriptsCMake <= 3.19 Linux binaries used a capital `L` in the name ( `cmake-3.19.0-Linux-x86_64.sh` ), but starting in 3.20 the names are all lowercase.
This is being reported as CI / scripts are now breaking when they try to compute the downl...CMake <= 3.19 Linux binaries used a capital `L` in the name ( `cmake-3.19.0-Linux-x86_64.sh` ), but starting in 3.20 the names are all lowercase.
This is being reported as CI / scripts are now breaking when they try to compute the download url based on the CMake version:
```
wget cmake.org/files/v${MAJOR}.${MINOR}/cmake-${MAJOR}.${MINOR}.${PATCH}-Linux-x86_64.sh
```https://gitlab.kitware.com/cmake/cmake/-/issues/21971CHECK_LIBRARY_EXISTS broken by CMAKE_TRY_COMPILE_TARGET_TYPE==STATIC_LIBRARY2021-03-24T18:45:01-04:00Jonas VautherinCHECK_LIBRARY_EXISTS broken by CMAKE_TRY_COMPILE_TARGET_TYPE==STATIC_LIBRARYWhen building Curl for iOS, I get the following error:
```
ld: library not found for -lsocket
```
I previously [opened an issue on Curl](https://github.com/curl/curl/issues/6789), but I think it may be related to CMake. I would like t...When building Curl for iOS, I get the following error:
```
ld: library not found for -lsocket
```
I previously [opened an issue on Curl](https://github.com/curl/curl/issues/6789), but I think it may be related to CMake. I would like to mention that I have been building Curl for iOS for years using the same toolchain, and it still works on the github macOS machines in CI (but they are still on macOS 10, I am on 11.2.3).
According to [this StackOverflow answer](https://stackoverflow.com/a/19860358), I believe that `libsocket` is not a thing with iOS:
> I'm not really sure about libintl, but libsocket is a library that only exists on System V-style Unixes (e.g. Solaris, HP-UX). If you're on Linux or a BSD-derivative (that includes Mac OS X), then you don't need to link to libsocket because sockets are implemented in libc which is linked in by default. Try linking without -lsocket and -lintl.
Moreover, looking for it in my iPhoneOS sdk, I cannot find it:
```
% find /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk/ | grep socket
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk//usr/include/sys/socket.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk//usr/include/sys/socketvar.h
```
I tried to `CHECK_LIBRARY_EXISTS` both for my macOS 11.2.3 and for iOS, using [this ios cmake toolchain](https://github.com/mavlink/MAVSDK/blob/main/tools/ios.toolchain.cmake). It finds it for iOS, which I don't understand.
Here is my test CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.10.2)
project(test_libsocket_exists)
include(CheckLibraryExists)
message(STATUS "Looking for libsocket in ${CMAKE_LIBRARY_PATH}")
check_library_exists("socket" connect "${CMAKE_LIBRARY_PATH}" HAVE_LIBSOCKET)
if(${HAVE_LIBSOCKET})
message(STATUS "Found libsocket!")
else()
message(STATUS "Did not find libsocket")
endif()
```
For macOS, I ran it with:
```
cmake -Bbuild -S.
```
and got the following output:
```
-- Looking for libsocket in
-- Looking for connect in socket
-- Looking for connect in socket - not found
-- Did not find libsocket
```
Note how `${CMAKE_LIBRARY_PATH}` is empty: "Looking for libsocket in".
For iOS, I ran the test with:
```
cmake -DCMAKE_TOOLCHAIN_FILE=/tmp/ios.toolchain.cmake -DPLATFORM=OS64 -Bbuild -S.
```
and got the following output:
```
-- Looking for libsocket in
-- Looking for connect in socket
-- Looking for connect in socket - found
-- Found libsocket!
```
Again, `${CMAKE_LIBRARY_PATH}` is empty, but this time it found something...
Am I right in thinking that this may be a bug? Again, Curl currently builds fine on the github CI macOS machines (which run macOS 10 and possibly an older iPhoneOS sdk).https://gitlab.kitware.com/cmake/cmake/-/issues/21968FindMPI: hipcc 4.1 w/ OpenMPI2021-08-09T19:11:12-04:00Axel HueblFindMPI: hipcc 4.1 w/ OpenMPII realized in our CI (WarpX, ECP), that since the update this week from 3.19.6 to 3.19.7, CMake cannot find OpenMPI anymore if one compiles with AMD's `hipcc` (in parallel version 4.0.20496-4f163c68 updated to 4.1.21072-c3eb5ccc).
The p...I realized in our CI (WarpX, ECP), that since the update this week from 3.19.6 to 3.19.7, CMake cannot find OpenMPI anymore if one compiles with AMD's `hipcc` (in parallel version 4.0.20496-4f163c68 updated to 4.1.21072-c3eb5ccc).
The packages installed are:
https://github.com/ECP-WarpX/WarpX/blob/development/.github/workflows/dependencies/hip.sh
```bash
# Ref.: https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html#ubuntu
wget -q -O - http://repo.radeon.com/rocm/rocm.gpg.key \
| sudo apt-key add -
echo 'deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ xenial main' \
| sudo tee /etc/apt/sources.list.d/rocm.list
echo 'export PATH=$PATH:/opt/rocm/bin:/opt/rocm/profiler/bin:/opt/rocm/opencl/bin' \
| sudo tee -a /etc/profile.d/rocm.sh
# we should not need to export HIP_PATH=/opt/rocm/hip with those installs
sudo apt-get update
# Ref.: https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html#installing-development-packages-for-cross-compilation
# meta-package: rocm-dkms
# OpenCL: rocm-opencl
# other: rocm-dev rocm-utils
sudo apt-get install -y --no-install-recommends \
build-essential \
gfortran \
libnuma-dev \
libopenmpi-dev \
openmpi-bin \
rocm-dev \
rocfft \
rocrand
# activate
#
source /etc/profile.d/rocm.sh
```
Generic HIP + MPI config call:
```bash
source /etc/profile.d/rocm.sh
hipcc --version # 4.1.21072-c3eb5ccc
export CXX=$(which hipcc)
export CC=$(which hipcc)
cmake -S . -B build -DCMAKE_VERBOSE_MAKEFILE=ON
cmake --build build -j 2
```
The error message is:
```
-- Could NOT find MPI_C (missing: MPI_C_WORKS)
-- Found MPI_CXX: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (found version "3.1")
CMake Error at /usr/local/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
Could NOT find MPI (missing: MPI_C_FOUND C) (found version "3.1")
Reason given by package: MPI component 'Fortran' was requested, but language Fortran is not enabled.
```
Note that the "reason messsage" is likely tainted by !5801 (unless this one was backported to 3.19.7).
CI action history: https://github.com/ECP-WarpX/WarpX/commits/developmenthttps://gitlab.kitware.com/cmake/cmake/-/issues/21967CUDA: Cannot target CUDA Linker option "Perform Device Link" for static libra...2021-03-24T09:47:05-04:00Robert ChisholmCUDA: Cannot target CUDA Linker option "Perform Device Link" for static library compilationWe have a [CUDA project](https://github.com/FLAMEGPU/FLAMEGPU2) using CMake which builds a static library, and then several targets which depend on the static library.
All targets use the CMake setting `CUDA_SEPARABLE_COMPILATION ON` to...We have a [CUDA project](https://github.com/FLAMEGPU/FLAMEGPU2) using CMake which builds a static library, and then several targets which depend on the static library.
All targets use the CMake setting `CUDA_SEPARABLE_COMPILATION ON` to enable relocatable device code.
Our project builds fine, however if we modify any CUDA within the static library and perform an incremental build on Windows/Visual Studio, we receive a link error from nvcc ('fatbinlinkerror') as the device code within the static library has not been re-linked. Hence we must always perform rebuilds, which takes significantly longer than an incremental build would.
We have reported this issue as a bug to the Nvidia's CUDA compiler team, and received a response notifying us that it was due to the static library not being told to perform a device link (the highlighted setting in the below screenshot). They also clarified that GCC always does a full device link, which is why that remains unaffected.
Looking through our CUDA targets, the two static libraries (created with `add_library(${NAME} STATIC ${SRC})`) have this setting disabled, and the executable targets (created with `add_executable(${NAME} ${SRC})`) all have it enabled. I can't see any obvious way to manually enable this setting via CMake (e.g. [FindCUDA docs](https://cmake.org/cmake/help/latest/module/FindCUDA.html)). My assumption would be that this setting should always be enabled for any target with `CUDA_SEPARABLE_COMPILATION` enabled, however as a C/C++ static library does not have a link stage this has been overlooked in the case of CUDA.
![image](/uploads/3128f6daa02e01b5eac571125497b23d/image.png)
Here's the full quote of the reply I received from reporting the bug to NVidia. I don't believe I can link to the actual bug report I sent them, as the nvcc bug reporting system is mostly private.
> Thanks for reporting this ticket with reproducer . I do see the same behavior following the build steps you described . On windows , we had -rdc to generate relocatable device code , you do enabled it when build the device code lib (GPU codes), but you didn't enable the dlink option when generate this lib . The dlink is done when generating the final executable . After the first build , when you modify the devices codes in lib , VS would only detect there is incrementally changes libs and only do the host linking incrementally again . So as you see some device symbols may not found in the linking .
>
> On linux , we usually do all links again especially when device codes are changed . As you can see your whole project may cost huge time to do a rebuild , so if there is only device codes in static libs and your parent project contains only host codes , enable the dlink in static libs is a good option for you . I tried on your project that should work , note that when you changed to enable the dlink , first rebuild is still needed .https://gitlab.kitware.com/cmake/cmake/-/issues/21965transitive usage requirements passed through `PRIVATE` dependencies2021-03-24T09:55:46-04:00Tim Blechmanntransitive usage requirements passed through `PRIVATE` dependenciesreading the 'transitive usage requirements' section there is the example:
```
add_library(archive archive.cpp)
target_compile_definitions(archive INTERFACE USING_ARCHIVE_LIB)
add_library(serialization serialization.cpp)
target_compile_...reading the 'transitive usage requirements' section there is the example:
```
add_library(archive archive.cpp)
target_compile_definitions(archive INTERFACE USING_ARCHIVE_LIB)
add_library(serialization serialization.cpp)
target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB)
add_library(archiveExtras extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)
target_link_libraries(archiveExtras PRIVATE serialization)
# archiveExtras is compiled with -DUSING_ARCHIVE_LIB
# and -DUSING_SERIALIZATION_LIB
add_executable(consumer consumer.cpp)
# consumer is compiled with -DUSING_ARCHIVE_LIB
target_link_libraries(consumer archiveExtras)
```
this comes with the following explanation:
> Because archive is a PUBLIC dependency of archiveExtras, the usage requirements of it are propagated to consumer too. Because serialization is a PRIVATE dependency of archiveExtras, the usage requirements of it are not propagated to consumer.
https://cmake.org/cmake/help/git-stage/manual/cmake-buildsystem.7.html#transitive-usage-requirements
-----
compiling this example gives me the following:
```
➜ b ninja -v
[1/8] /usr/bin/c++ -DUSING_ARCHIVE_LIB -DUSING_SERIALIZATION_LIB -MD -MT CMakeFiles/archiveExtras.dir/extras.o -MF CMakeFiles/archiveExtras.dir/extras.o.d -o CMakeFiles/archiveExtras.dir/extras.o -c ../extras.cpp
[2/8] /usr/bin/c++ -DUSING_ARCHIVE_LIB -DUSING_SERIALIZATION_LIB -MD -MT CMakeFiles/consumer.dir/consumer.o -MF CMakeFiles/consumer.dir/consumer.o.d -o CMakeFiles/consumer.dir/consumer.o -c ../consumer.cpp
[3/8] /usr/bin/c++ -MD -MT CMakeFiles/archive.dir/archive.o -MF CMakeFiles/archive.dir/archive.o.d -o CMakeFiles/archive.dir/archive.o -c ../archive.cpp
[4/8] /usr/bin/c++ -MD -MT CMakeFiles/serialization.dir/serialization.o -MF CMakeFiles/serialization.dir/serialization.o.d -o CMakeFiles/serialization.dir/serialization.o -c ../serialization.cpp
[5/8] : && /snap/cmake/846/bin/cmake -E rm -f libserialization.a && /usr/bin/ar qc libserialization.a CMakeFiles/serialization.dir/serialization.o && /usr/bin/ranlib libserialization.a && :
[6/8] : && /snap/cmake/846/bin/cmake -E rm -f libarchive.a && /usr/bin/ar qc libarchive.a CMakeFiles/archive.dir/archive.o && /usr/bin/ranlib libarchive.a && :
[7/8] : && /snap/cmake/846/bin/cmake -E rm -f libarchiveExtras.a && /usr/bin/ar qc libarchiveExtras.a CMakeFiles/archiveExtras.dir/extras.o && /usr/bin/ranlib libarchiveExtras.a && :
[8/8] : && /usr/bin/c++ -rdynamic CMakeFiles/consumer.dir/consumer.o -o consumer libarchiveExtras.a libarchive.a libserialization.a && :
```
most notably `consumer.cpp` is compiled with both `-DUSING_ARCHIVE_LIB` and with `-DUSING_SERIALIZATION_LIB`.
this seems to contradict the statement:
> Because serialization is a PRIVATE dependency of archiveExtras, the usage requirements of it are not propagated to consumer.
which would imply that `consumer.cpp` is compiled with `-DUSING_ARCHIVE_LIB`, but not with `-DUSING_SERIALIZATION_LIB`https://gitlab.kitware.com/cmake/cmake/-/issues/21964XL/Fortran: CMake is failing to report the 'tweak' compiler version field2021-03-24T13:02:05-04:00Aaron BlackXL/Fortran: CMake is failing to report the 'tweak' compiler version fieldCMake is failing to report the 'tweak' field in the CMAKE_Fortran_COMPILER_VERSION for IBM XLF.
Test cmake file:
```
set(CMAKE_C_COMPILER "xlc" CACHE PATH "")
set(CMAKE_CXX_COMPILER "xlc++" CACHE PATH "")
set(CMAKE_Fortran_COMPI...CMake is failing to report the 'tweak' field in the CMAKE_Fortran_COMPILER_VERSION for IBM XLF.
Test cmake file:
```
set(CMAKE_C_COMPILER "xlc" CACHE PATH "")
set(CMAKE_CXX_COMPILER "xlc++" CACHE PATH "")
set(CMAKE_Fortran_COMPILER "xlf90" CACHE PATH "")
enable_language(C CXX Fortran)
project(FOO)
```
Output:
```
-- The C compiler identification is XLClang 16.1.1.9
-- The CXX compiler identification is XLClang 16.1.1.9
-- The Fortran compiler identification is XL 16.1.1
```
Desired output:
```
-- The C compiler identification is XLClang 16.1.1.9
-- The CXX compiler identification is XLClang 16.1.1.9
-- The Fortran compiler identification is XL 16.1.1.9
```
Example of ELF from executable:
```
readelf -p .comment test_executable
String dump of section '.comment':
[ 50f] IBM XL Fortran for Linux, V16.1.1 (5725-C75, 5765-J15) Version 16.01.0001.0009
```
Is it possible CMake is using the 'VX.X.X' portion instead of the 'Version X.X.X.X' portion?https://gitlab.kitware.com/cmake/cmake/-/issues/21961project(): Introduce PROJECT_IS_TOP_LEVEL normal and <project-name>_IS_TOP_LE...2021-03-25T10:29:31-04:00friendlyanonproject(): Introduce PROJECT_IS_TOP_LEVEL normal and <project-name>_IS_TOP_LEVEL variablesTo make a project's CML file trivial to consume by directly (`add_subdirectory`) or indirectly (`FetchContent` or libraries wrapping it like [CPM.cmake](https://github.com/cpm-cmake/CPM.cmake)) making it part of the build tree, there are...To make a project's CML file trivial to consume by directly (`add_subdirectory`) or indirectly (`FetchContent` or libraries wrapping it like [CPM.cmake](https://github.com/cpm-cmake/CPM.cmake)) making it part of the build tree, there are certain things that must only conditionally be executed, such as inclusion of the `CPack` module, enabling tests and other targets only useful for developers of the given project, [fixing the include dir location](https://github.com/Dobiasd/FunctionalPlus/issues/222), basically doing anything other than providing targets of the project intended to be consumed.
CMake automatically providing variables to do this check would fit in well with the others.
Behavior:
---
A call to `project(Example)` would set the normal variable `PROJECT_IS_TOP_LEVEL` and the cache variable `Example_IS_TOP_LEVEL` to the value returned by `cmMakefile#IsRootMakefile()`.
---
Would this require an additional policy due to the new variables?
If this is something that is desirable, I will submit a PR for the implementation and documentation.https://gitlab.kitware.com/cmake/cmake/-/issues/21959CMP0116 warning triggered even though path given to DEPFILE is absolute2021-03-30T00:11:30-04:00Craig ScottCMP0116 warning triggered even though path given to DEPFILE is absoluteI'm using CMake 3.20.0-rc5 on Qt6 sources with the Ninja generator on macOS. In one of the repos, there is a call to `add_custom_command()` which includes a `DEPFILE` keyword. The argument that follows after that keyword is always an abs...I'm using CMake 3.20.0-rc5 on Qt6 sources with the Ninja generator on macOS. In one of the repos, there is a call to `add_custom_command()` which includes a `DEPFILE` keyword. The argument that follows after that keyword is always an absolute path. This call occurs in a subdirectory, not the top level CMakeLists.txt file. You can find the relevant code [here](https://github.com/qt/qtdeclarative/blob/759446963d89af39d7ec7ee891561028d8a1e2f2/src/qml/Qt6QmlMacros.cmake#L830). That code currently specifies the .cpp file in that depfile as relative, but even after I locally ensure it is absolute, the warning discussed here is still emitted.
The CMP0116 policy is not set (policy range in effect at that point is 3.14...3.19). According to the docs, I would not expect this situation to issue any warning, since an absolute path given to `DEPFILE` is unambiguous and therefore not subject to any misinterpretation due to the problem the policy addresses. Despite this, after the configure stage but before the generation stage, I see many CMP0116 warnings that stem from this `add_custom_command()` call. An example warning looks like this:
```
CMake Warning (dev) at qtdeclarative/src/qml/Qt6QmlMacros.cmake:831 (add_custom_command):
Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
add_custom_command(). Run "cmake --help-policy CMP0116" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Call Stack (most recent call first):
qtdeclarative/src/qml/CMakeLists.txt:661 (qt6_qml_type_registration)
This warning is for project developers. Use -Wno-dev to suppress it.
```
Looking at the code [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.20.0-rc5/Source/cmLocalNinjaGenerator.cxx#L661-682), it appears the warning is triggered any time the current binary directory is different to the top level binary directory and CMP0116 is not set, regardless of whether the path to the depfile or its contents use relative or absolute paths.
Locally, I have explicitly set the policy around that call to confirm that all the warnings go away when CMP0116 is set to NEW, but this should not be necessary. I also confirmed by printing out the filename that it was indeed always an absolute path.Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21956FindMPI return the wrong path to Intel oneMPI headers2021-03-22T16:26:45-04:00Colin BrissonFindMPI return the wrong path to Intel oneMPI headersI try to use Intel oneAPI 2021.1 to compile [Wordrank](https://github.com/shihaoji/wordrank), but I'm running into some issues.
I first installed CMake 3.19.6 to avoid the [single quote error](https://gitlab.kitware.com/cmake/cmake/-/is...I try to use Intel oneAPI 2021.1 to compile [Wordrank](https://github.com/shihaoji/wordrank), but I'm running into some issues.
I first installed CMake 3.19.6 to avoid the [single quote error](https://gitlab.kitware.com/cmake/cmake/-/issues/21634). However, during compilation I get the following message:
```
-- The Fortran compiler identification is Intel 20.2.1.20201112
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /opt/intel/oneapi/compiler/2021.1.1/linux/bin/intel64/ifort - skipped
-- Checking whether /opt/intel/oneapi/compiler/2021.1.1/linux/bin/intel64/ifort supports Fortran 90
-- Checking whether /opt/intel/oneapi/compiler/2021.1.1/linux/bin/intel64/ifort supports Fortran 90 - yes
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.40") found components: program_options
-- Could NOT find MPI_C (missing: MPI_C_HEADER_DIR) (found version "3.1")
-- Could NOT find MPI_CXX (missing: MPI_CXX_HEADER_DIR) (found version "3.1")
-- Could NOT find MPI_Fortran (missing: MPI_Fortran_F77_HEADER_DIR MPI_Fortran_MODULE_DIR) (found version "3.1")
CMake Error at /snap/cmake/805/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND MPI_Fortran_FOUND)
(found version "3.1")
Call Stack (most recent call first):
/snap/cmake/805/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:582 (_FPHSA_FAILURE_MESSAGE)
/snap/cmake/805/share/cmake-3.19/Modules/FindMPI.cmake:1722 (find_package_handle_standard_args)
CMakeLists.txt:15 (find_package)
```
When I check [CMakeOutput.log](/uploads/5aefe19505fe20c113beac58a549ce4a/CMakeOutput.log) I see that the path to the MPI headers directory is wrong: it's `/opt/intel/oneapi/mpi/2021.1.1//include` instead of `/opt/intel/oneapi/mpi/2021.1.1/include`. Could it be the issue? If it's, how can I fix it?https://gitlab.kitware.com/cmake/cmake/-/issues/21951CPack/RPM: Setting CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON breaks 'make package'2021-04-15T10:16:56-04:00Greg MajszakCPack/RPM: Setting CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON breaks 'make package'I have the follow files:
CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.17.3)
project(CMakeCPackBug VERSION 1.0.0)
set(CMAKE_CXX_STANDARD 11)
add_executable(main main.cpp)
include(GNUInstallDirs)
# Install empty director...I have the follow files:
CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.17.3)
project(CMakeCPackBug VERSION 1.0.0)
set(CMAKE_CXX_STANDARD 11)
add_executable(main main.cpp)
include(GNUInstallDirs)
# Install empty directory /var/log/data
install(DIRECTORY
DESTINATION ${CMAKE_INSTALL_LOCALSTATEDIR}/log/data
COMPONENT common)
# Install file README.txt to doc directory
install(FILES
${PROJECT_SOURCE_DIR}/README.txt
DESTINATION ${CMAKE_INSTALL_DOCDIR}
COMPONENT common)
set(CPACK_COMPONENTS_ALL common main)
set(CPACK_GENERATOR RPM)
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VERSION ${PACKAGE_VERSION})
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_RPM_DEBUGINFO_PACKAGE ON)
# TODO - FIXME! Enabling this breaks 'make package', why?
#set(CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON)
set(CPACK_RPM_CONFIG_DEFAULT_GROUP ${PROJECT_NAME})
set(CPACK_RPM_CONFIG_DEFAULT_USER ${PROJECT_NAME})
set(CPACK_RPM_FILE_NAME RPM-DEFAULT)
set(CPACK_RPM_MAIN_COMPONENT main)
set(CPACK_RPM_PACKAGE_RELEASE 1)
set(CPACK_RPM_PACKAGE_RELEASE_DIST ON)
include(CPack)
main.cpp:
#include <cstdlib>
int main()
{
system("cmake3 --version");
}
```
README.txt:
```
CMAKE(1) CMake CMAKE(1)
NAME
cmake - CMake Command-Line Reference
```
When run with this software configuration:
```console
$ cmake3 --version
cmake3 version 3.17.5
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
$ uname -r
3.10.0-1160.15.2.el7.x86_64
```
Works as expected and the generated RPMs look correct. However, if I enable 'set(CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE ON)', 'make package' fails with this error:
```
error: Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var
error: Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var/log
error: Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var/log/data
Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var
Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var/log
Directory not found: /home/gmajszak/CMakeCPackBug/build/_CPack_Packages/Linux/RPM/CMakeCPackBug-1.0.0-Linux/main/usr/var/log/data
```
Is this a misconfiguration or a bug in CMake/CPack?
Thanks,
GregDomen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/21948find_package for PostgreSQL does not work in 3.20-rc42021-03-17T08:47:03-04:00Richardfind_package for PostgreSQL does not work in 3.20-rc4There seems to be a regression with find_package and PostgreSQL.
Following code works in 3.19.7, but does not in 3.20-rc4:
```
set(PostgreSQL_ROOT "/usr/pgsql-9.6")
find_package(PostgreSQL REQUIRED 9.6.2)
```
I get following error:
```
...There seems to be a regression with find_package and PostgreSQL.
Following code works in 3.19.7, but does not in 3.20-rc4:
```
set(PostgreSQL_ROOT "/usr/pgsql-9.6")
find_package(PostgreSQL REQUIRED 9.6.2)
```
I get following error:
```
CMake Error at <cmake_dir>/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find PostgreSQL (missing: 9.6.2) (found version "9.6.2")
Call Stack (most recent call first):
<cmake_dir>/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
<cmake_dir>/playground/cmake/Modules/FindPostgreSQL.cmake:269 (find_package_handle_standard_args)
CMakeLists.txt:20 (find_package)
```https://gitlab.kitware.com/cmake/cmake/-/issues/21947Python3.framework linking regression2021-03-17T18:19:41-04:00clintonstimpsonPython3.framework linking regressionThe attached example illustrates a possible regression with computing RPATHS from Frameworks on macOS.
It looks like 5772ca0a53 tries to fix this for CMake 3.20, but maybe it wasn't fixed in the right place. See also #21293.
This examp...The attached example illustrates a possible regression with computing RPATHS from Frameworks on macOS.
It looks like 5772ca0a53 tries to fix this for CMake 3.20, but maybe it wasn't fixed in the right place. See also #21293.
This example also illustrates difficulties with FindPython3 on macOS when finding the Python3 included with Xcode.
[CMakeLists.txt](/uploads/9bc4fbbb68cabd68c64330ca661a39c6/CMakeLists.txt)
[main.cpp](/uploads/b5d895a6f60bae9fe6cfde3fd4d67951/main.cpp)