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
If more than one content link references the same object, the build
system may launch multiple download processes for the same object
concurrently. Use whichever one finishes first, and discard the others.
Without this, we replace the objects and use the last finisher instead
of the first. This is okay on non-Windows platforms where `rename(2)`
gives reliable atomic replacement. However, on Windows platforms and
NTFS this is less reliable. I've observed `MoveFileEx` somehow cause
another process to get `ERROR_SHARING_VIOLATION` when attempting to read
the destination file. We may be able to improve the `file(RENAME)`
implementation on modern Windows 10 versions, but for ExternalData's use
case it is simpler to just not replace existing objects.
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
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
bdc40742bd CMakeDetermineCompilerId: Test without COMPILER_ID_FLAGS if REQUIRE_SUCCESS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5863
C11 was made default in LLVM commit ab506adf7d3ced6abcaf42f92de3d6cd15fa19e8,
released in 3.5.2.
C99 was made default in LLVM commit 17f76e04d244c80e70f1c81c94d4524b53d9772d,
released in 2.1. It was flipped a few times between C89 and C99 during the 2.1
cycle, but the C89 default never made it into a release.
C89, C99 flags in LLVM commit ff43821d5380ee38aff421701f1d461242b524ee.
C90 flag in LLVM commit 229ce60fc9983df5f7e83e25fa6b5c0ca4d2b135.
C1x flag in LLVM commit a686b5f8bf7b5a2ab636c0c2de5ad4c174aa33e0.
C11 flag in LLVM commit 6784aeb9ef96e5735850fa7226ed0cb45cb82e75.
Mark C90, C99 full support since 2.1. Might've been possibly a little later,
but source spelunking that much back is difficult.
Mark C11 full support since 3.0, which added _Static_assert in LLVM commit
3d9cbdc3e66e274d5d3cb94ce81a65478d9baae0.
Additional Changes: Rework the documentation of FindIntl
NOTES:
Reorder the REQUIRED_VARS arguments so find_package reports the library
instead of the include directory.
Handle Intl_LIBRARY in the same way how FindIconv handles it in case of glibc.
If the VERSION_VAR argument is an empty string nothing happens.
Fixes: #21857
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.
In commit 4620cf77f2 (Clang: Remove unused CUDA implicit link variables,
2021-02-14) we removed some references. It turns out they are non-empty
and necessary if using a non-scattered installation.
Fixes: #21863
