They seem to actually cause trouble, like an error reported on IRC where some
but not all CMake invocations may end up with an error like this:
CMake Warning (dev) at /usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:74 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted keywords like ")" will no longer be interpreted as keywords when the
policy is set to NEW. Since the policy is not set the OLD behavior will be
used.
Call Stack (most recent call first):
/usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:179 (cmake_parse_implicit_include_line)
/usr/share/cmake/Modules/CMakeDetermineCompilerABI.cmake:119 (cmake_parse_implicit_include_info)
/usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:26 (CMAKE_DETERMINE_COMPILER_ABI)
CMakeLists.txt:24 (project)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:74 (if):
if given arguments:
"GNU" "STREQUAL" "SunPro" "AND" "(" ")" "MATCHES" "-D__SUNPRO_C" "OR" ")" "MATCHES" "-D__SUNPRO_F" ")"
I suspect that the line ends up being just ")", which then causes this error.
Since commit f3eed2c49d (cmGlobalNinjaGenerator: use P1689 dependency
file format for Fortran, 2019-03-12, v3.20.0-rc1~454^2), Fortran stopped
working in a build tree whose path contains a symlink. The reason is
that the P1689r3 format's `work-directory` field gets populated with the
realpath (via `getcwd`) of the build tree instead of the logical path to
the build tree used for generating relative paths in `build.ninja`.
This causes the `Fortran.dd` file to get absolute (real)paths to `.o`
files, and Ninja does not match them with the relative `.o` file paths
in `build.ninja`.
Fix this by dropping use of the `work-directory` field. This restores
our prior approach of generating paths in the dyndep file using the same
forms of paths received from the buildsystem generator. The P1689r3
paper's format may need to be revised to account for this.
Fixes: #21683
18bd63af41 ci: enable FindProtobuf gRPC test on Linux builds
27adb6c78e gitlab-ci: update Debian base images
89478e643f gitlab-ci: update to Fedora 34 base images
6ff48b862c ci: add gRPC to Debian and Fedora base images
4ad8bfcd9b ci: add codespell to Fedora base image
fa261d1b7d ci: add Qt 6 to Fedora base image
82fc490f93 ci: update to Fedora 34 for Linux base images
a69e6dba92 gitlab-ci: update to Fedora 34 for upload jobs
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6117
When cross compiling from Windows to a platform that uses SONAMEs, real
symlinks are now created for the VERSION and SOVERSION links instead of
copies, if the user has the necessary privileges.
Fixes: #22128
add_jar() currently requires (undocumented) that resources be supplied
as relative paths. The resources *may* then end up in a path which does
not reflect the original path particularly when performing out-of-source
builds. This change adds a RESOURCE (and NAMESPACE) parameter and a
function to add the names resources into the named namespace within the
jar- and thus address both of these problems.
Fixes: #22101
