Refactoring in commit bdc40742bd (CMakeDetermineCompilerId: Test without
COMPILER_ID_FLAGS if REQUIRE_SUCCESS, 2021-02-27, v3.20.0-rc3~6^2) added
an extra macro layer through which flag strings are passed. That caused
an extra level of argument re-parsing, and broke flags with backslashes.
Pass flags to the helper macro through variable names instead.
Fixes: #22041
Update the change from commit f7f3d8987a (FindBLAS: Add dependency of
OpenBLAS on OpenMP for BLA_STATIC, 2020-11-10, v3.20.0-rc1~492^2):
* If C is not enabled, find CXX OpenMP libraries instead.
* Do not use BLA_STATIC's custom CMAKE_FIND_LIBRARY_SUFFIXES for OpenMP.
It can break projects that already call `find_package(OpenMP)` and
expect a shared library. Whether OpenMP is static is orthogonal to
whether BLAS is static.
Fixes: #22039
Issue: #16221
Since commit 2c71d051fa (Makefiles Generators: use compiler for
dependencies generation, 2020-10-18, v3.20.0-rc1~392^2) we invoke `nvcc`
for CUDA < 10.2 a second time in order to generate a depfile. When
`CMAKE_CUDA_HOST_COMPILER` is set, the second invocation is missing its
`-ccbin=` option, even after refactoring in commit 8981e3e7cc
(NVIDIA-CUDA: rely on new capabilities for deps generation, 2020-12-02,
v3.20.0-rc1~362^2).
Ideally we should move the `-ccbin=` flag into `Compiler/NVIDIA-CUDA`,
but that will add `CMAKE_CUDA_HOST_COMPILER` support on Windows in
command-line generators but not the Visual Studio generators.
For now, add the flag to the depfile command specifically.
Fixes: #22037
Refactoring in commit b12aec6c8d (BinUtils: prefer bin utils matching
the compiler version extension, 2020-12-11, v3.20.0-rc1~171^2)
accidentally leaked a `TOOL` variable. Name temporary variables with a
private prefix.
Fixes: #22035
c3d0b25514 UseSWIG: Transform swig depfile to match Ninja generator paths
8c525d7e16 UseSWIG: Run using policy settings from includer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5983
Since CMake 3.19, we no longer support macOS SDKs older than 10.5,
which corresponds to Xcode 3. Supporting older Xcode versions for
device platforms is also not realistic. We therefore expect the -rpath
linker option should always be supported now.
When targeting iOS, tvOS or watchOS, the previous disabling of -rpath
support meant that the install_name_dir of shared libraries and
frameworks was unable to use @rpath. This resulted in embedding
absolute paths for their install_name. When they were embedded in an
app bundle, this would cause the app to fail at runtime. By enabling the
-rpath linker option, the default install_name_dir is now @rpath for these platforms, which results in binaries that do work at runtime.
Fixes: #20036
The NVHPC compiler does not have any implicit link directories that can
be used to detect `CMAKE_LIBRARY_ARCHITECTURE`, but it does have
implicit object files. Extract implicit object file paths from link
lines and check them for the `CMAKE_LIBRARY_ARCHITECTURE` pattern.
Issue: #22024
The change in commit 657fc3a9a7 (CMakeDetermineCompilerABI: Parse
library arch from versioned paths, 2021-02-03, v3.20.0-rc1~40^2) caused
`CMAKE_LIBRARY_ARCHITECTURE` to be populated on non-multiarch platforms
if their compilers happen to use `$arch/$version` library directories.
Revert the use of versioned library paths.
Fixes: #22024
Since commit 89b01b04fa (UseSWIG: use swig tool to generate
dependencies, 2021-01-12, v3.20.0-rc1~120^2) we use a tool-provided
depfile to extract dependencies under the Ninja generator. Enable
`CMP0116` to ensure depfile paths are translated to match what the Ninja
generator writes to the build manfiest.
Fixes: #22029
Backport commit de7f0aa6c0 (UseSWIG: avoid spurious policy warnings,
2021-02-11) to the 3.20 release branch. Projects need to be able to
control policies.
Issue: #22029
Set `CMAKE_SYSTEM_PROGRAM_PATH` in `Platform/Android-Initialize` instead
of `Platform/Android` so it can be used in `CMakeFindBinUtils`.
Also add the names `llvm-strip` and `llvm-ranlib` for the corresponding
tools.
Since commit c30d06b7e6 (FindIntl: Add imported target, 2020-10-06,
v3.20.0-rc1~687^2) we use `check_symbol_exists` to check whether the
`intl` library is built in to the C library. On some platforms the
tested symbols are provided as macros so the check passes without
linking any symbol. Instead, check whether a sample source file both
compiles and links.
Fixes: #21979
Since commit ab8bd48352 (FindPkgConfig: Search for pkg-config.bat file
on a Windows host, 2020-09-25, v3.19.0-rc1~98^2) we prefer
`pkg-config.bat` over `pkg-config` regardless of the order they appear
in the `PATH`. Tell `find_program` to consider all names in each
directory so that the first one in `PATH` of any name wins.
Issue: #21239
The Windows driver does not like the `-f` form of this option.
Note that we prefer `-Qiopenmp/-fiopenmp` over `-Qopenmp/-fopenmp` in
order to generate LLVM IR with parallelization information, which the
backend uses to generate parallelized code.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Previously were checking for the `__CRAYXC` and `__CRAYXE` predefined
macros. These macros reflect the platform that the compiler wrapper is
running on, i.e. Cray XC and Cray XE machines. They are not defined on
other platforms such as Apollo80.
Switch to the `__CRAYXT_COMPUTE_LINUX_TARGET` macro. The Cray cc/CC/ftn
wrappers always define this macro on the command line. This macro has
been in use for many years, and is believed to be a reliable way to
detect current and older Cray compiler wrappers.
Fixes: #21904
Refactoring of the ExternalProject and FetchContent modules moved
the commands into CMake scripts. This broke custom commands that
used shell redirection or special build tool variables of the form
$(MakeVar). Undo the sequence of commits that performed this
refactoring and follow-up fixes associated with it.
The following commits are reverted by this change:
4f3d1abbb4 (ExternalProject: Refactor pre-configure steps to support
no-target uses, 2021-02-05)
17e5516e60 (FetchContent: Invoke steps directly and avoid a separate
sub-build, 2021-01-29)
bd876f3849 (FetchContent: Restore patch command support,
2021-02-18)
404cddb7bb (ExternalProject: Fix misuse of IS_NEWER_THAN in
timestamp checks, 2021-02-21)
b0da671243 (FetchContent: Don't update timestamps if files don't
change, 2021-02-18)
Fixes: #21892
In commit bda5e2ac8f (FindMatlab: Only include engine and dataarray
libraries if they are found, 2020-12-11, v3.20.0-rc1~297^2~1) we fixed
the imported target to contain optional libraries only if they are
found. Do the same for `Matlab_LIBRARIES`.
The justification in commit 9ee4a42813 (Cray: Fix Cray compiler
detection on new platforms, 2020-12-01, v3.19.2~26^2) confuses detection
of the CrayPrgEnv with identification of the Cray compiler. The
change regressed detection of the CrayPrgEnv on non-Cray compilers.
Revert it pending further investigation into the original problem.
Fixes: #21894
Cray 11.0 adds support for preprocessing with output written to a
specified file (instead of always next to the source). Use it to
enable Cray Fortran with the Ninja generator.
Patch-by: James Elliott
Fixes: #20731
005e2cdfb0 Android: Do not use gold for ndk >= r22
ed7a87f270 Tests: Update RunCMake.Android for NDK r22
4950d35733 Help: Document CMAKE_ANDROID_NDK_VERSION variable
746906242d Android: Detect NDK version number
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5862
The PGI ( and NVIDIA HPC ) compilers default C++ standard level
are based on the GCC system headers it is compiling against.
Therefore on newer platforms the default C++ level will be >= 11
and requesting C++98 compilation mode will fail as no explicit
flag will be set.
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) uses a different way of writing
out the step scripts and updating time stamps when steps are executed.
That inadvertently always wrote out the scripts for custom commands,
even when the contents didn't change. This caused their timestamp to
always be updated, resulting in those steps always being seen as
out-of-date and needing to be re-executed.
The way timestamps were checked to determine whether to re-execute
a step also did not adequately account for file systems which only have
second-resolution timestamps. The IS_NEWER_THAN if condition also
returns true when timestamps are the same, so one needs to use the
negative form to get a true "is newer than" test.
ExternalProject is not susceptible to this problem because it uses
file(GENERATE) to write out the script files and that only updates the file's
timestamp if the contents change. It also mostly leaves timestamp
checking to the build tool.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo downloads when they match exactly.
