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
8ef55dec29 Help: Add release notes for Fujitsu compiler support
4c74c86f40 FindBLAS/LAPACK: Add support for the Fujitsu SSL2 library
376c300b25 FindOpenMP: Add support for Fujitsu compilers
9e0a1cf03e FindMPI: Add support for the Fujitsu compiler wrappers
a237450948 Tests: Update for the FujitsuClang compiler
27579e9cf1 FujitsuClang: Add support for the Fujitsu compiler in Clang mode
a55feff69c Tests: Update for the Fujitsu compiler
3c867cff4a Fujitsu: Add support for the Fujitsu compiler in Trad mode
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Axel Huebl <axel.huebl@plasma.ninja>
Acked-by: Gilles Gouaillardet <gilles@rist.or.jp>
Merge-request: !5954
This should be front end compatible with vanilla clang but giving it a
unique identifier allows a project to pass additional options unique to
Fujitsu and outside the scope of a CMake builtin.
Define `PROJECT_IS_TOP_LEVEL` and `<PROJECT-NAME>_IS_TOP_LEVEL`. The
latter is a STATIC cache entry just like other `<PROJECT-NAME>_*`
variables so that it is globally scoped.
Issue: #20310Fixes: #21961
The names and formats of our VS flag tables are internal implementation
details. However, some institutions need to maintain support for
non-public VS platforms and toolsets. Provide a hook that their
projects can use to load custom flag table files. This helps avoid
distributing a custom CMake package within such institutions.
Document the hook itself, but explicitly specify that the files the
hook loads are not considered a stable interface.
30c835428f VS: Accept and translate '-T version=' values with three components
58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9
09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5903
30c835428f VS: Accept and translate '-T version=' values with three components
58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9
09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5903
The VS 16.8 and VS 16.9 toolset versions differ only in their third
component. The `vcvarsall` option `-vcvars_ver=` accepts a three
component version, so accept this format for VS toolset selection too.
Issue: #21922
CMake accepts the toolset version that is default in the current VS
version by matching the name later VS versions will use for the SxS
props files. It predicts the future name based on the first two
components of the current VS version's default toolset. However, this
heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9
because the latter's default toolset version is 14.28.29910, which did
not increment the second version component (unprecedented in VS).
Fix this by always using the requested version's SxS props file when it
exists, even if it matches the first two components of the current VS
version's default toolset. Also add a special case for the name VS
16.10 will use for VS 16.9's default toolset, so that it can be used
with VS 16.9 too.
Fixes: #21922
Run the script:
Utilities/Sphinx/update_versions.py --since v3.19.0 --overwrite
Manually restore the 3.20 version for `cmake_path`, which was originally
part of 3.19 but reverted and restored in 3.20.
Using a single ID 'IntelLLVM' for the suite of Intel compilers based on
the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran.
Data Parallel C++ will be handled in a separate commit.
The C and C++ definitions are based on the Clang definitions. The Intel
LLVM-based C and C++ compilers are based on the Clang front end, so
existing Clang options are more likely to be a good match than options
for the older Intel compilers.
Fortran is based on the older Fortran front end with the LLVM backend.
It has a similar interface to the older versions, though many options
are shared with the C and C++ compilers.
Fixes: #21561
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Identify the compilers as `NVHPC` to distinguish it from the older PGI
compilers from which they evolved, and from other `NVIDIA` compilers.
Fixes: #20887
The `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` variable added in
CMake 3.19 by commit ba497111f6 (VS: Add option for custom Win10 SDK
version maximum, 2020-08-20, v3.19.0-rc1~262^2) was documented as if it
worked for all generators but implemented only to override CMake's
builtin default for the VS 2015 max SDK version. Generalize the
variable to set a custom max SDK version for later VS versions too.
Fixes: #21720
The new target property `EXPORT_COMPILE_COMMANDS` associated with the
existing global variable can be used to optionally configure targets for
their compile commands to be exported.
Fixes: #19462
The target property `ISPC_HEADER_SUFFIX` and associated global
variable now can control the suffix used when generating the
C/C++ interoperability ISPC headers.
In addition the default suffix is now "_ispc.h" which matches the
common convention that the ISPC compiler team uses and recommends.
b7f0327dcd Tests: Cover macOS host architecture selection on Apple Silicon hosts
5f882f6ce5 macOS: Offer control over host architecture on Apple Silicon hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5589
Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
that we are running on Apple Silicon in a way that pierces Rosetta.
This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
hosts. However, macOS offers strong support for running processes under
an emulated `x86_64` architecture.
Teach CMake to select either `arm64` or `x86_64` as the host
architecture on Apple Silicon based on the architecture of its own
process. When CMake is built as a universal binary, macOS will select
whichever slice (architecture) is appropriate under the user's shell,
and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
variable to provide users with explicit control over the host
architecture selection regardless of CMake's own architecture.
Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to
the toolchain to use selected host architecture instead of letting the
toolchain pick.
Fixes: #21554
Revert commit 887f3a88a6 (Intel: Add Intel DPC++ compiler
identification, 2020-09-21, v3.19.0-rc1~124^2). The compiler has
already been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Fixes: #21551
Revert commit 5c3a93ab88 (Intel: Add Intel Clang compiler
identification, 2020-09-29, v3.19.0-rc1~68^2). The compiler has already
been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Issue: #21551
