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
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
In commit ce2dee9e5b (Xcode: Don't add framework as -framework argument
in linker info list, 2020-09-28, v3.19.0-rc1~47^2) we split up the path
to a framework into the directory and framework name parts, but only
retained the quoting on the directory part. Restore quoting of the
framework name.
Fixes: #21910
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
Upstream ninja commit `ad3d29fb53` (Put builder output through status
interface) from ninja PR 1899 changed the status output from stdout to
stderr. In particular, `ninja: no work to do` is now printed on stderr.
Update our RunCMake tests to accept this difference.
A few RunCMake test cases check for `ninja: no work to do`. For those,
move the message to stdout using `RunCMake_TEST_OUTPUT_MERGE`. The rest
of the test cases do not care about the message, so remove it from the
actual stderr content before comparing against that expected.
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Fixes: #21828
In commit bb61c2d024 (Clang: use -imsvc for system include dirs when
running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we added `-imsvc`
for all Clang compilers targeting the MSVC ABI. However, the option
only exists for the MSVC-like front-end. The GNU-like front-ends
use `-isystem`.
Fixes: #21789
Since commit 6a6f1d1edd (CTest: exit nonzero after
message(SEND_ERROR|FATAL_ERROR), 2020-04-03, v3.19.0-rc1~260^2), `ctest`
no longer runs tests if there are errors before the full set of tests is
defined. Such errors were previously treated more like warnings.
The change exposed some cases where we were issuing an error message but
proceeding to run tests anyway. The above commit downgraded one such
case (missing `DartConfiguration.tcl`) to a warning explicitly in order
to restore its former warning-like semantics.
Downgrade the Update step's diagnostic about modified or conflicting
files to a warning for the same reason.
Fixes: #21783
Xcode 12 doesn't allow nested builds within the same build directory.
That means we can no longer do an install by building the install target
when IOS_INSTALL_COMBINED is true. We can, however, still do an install
by running the cmake_install.cmake script or executing cmake --install,
since there is no outer build and therefore the associated SDK can be
built as a sub-build.
The non-build methods previously didn't work when
IOS_INSTALL_COMBINED was true because the generated install script
and the CMakeIOSInstallCombined script both made certain assumptions
that relied on being part of a build. Those assumptions are now
removed. A side-effect of this work is that cpack now also works from the
command line when IOS_INSTALL_COMBINED is true.
Relates: #21282Fixes: #20023
In commit f034b0f663 (CMake compilation: do not use compiler extensions,
2020-03-14, v3.18.0-rc1~494^2) we explicitly defined `_POSIX_C_SOURCE`
to ensure availability of POSIX APIs even when compiler extensions are
not enabled. Update the code to avoid redefining `_POSIX_C_SOURCE` if
it is already defined. This occurs when building our release binaries
as configured in `Utilities/Release/linux`, where we define
`_POSIX_C_SOURCE` explicitly on the compiler command line.
Documentation updates in commit 02f527c66a (Find: Provide global
controls for the `NO_[]_PATH` call options, 2019-06-12,
v3.16.0-rc1~541^2) accidentally switched the `find_library`
documentation to mention `INCLUDE` where it should be `LIB`.
While at it, update `find_file` and `find_path` to mention
`INCLUDE` and `PATH` in the order they are considered.
5389bb4274 Xcode: Don't hard-code SDK-provided implicit framework search paths
df08f8df30 cmComputeLinkInformation: Fix misspelt private variable name
375b307bae Apple: Fix linking to frameworks that do not exist until build time
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5760
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_75_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.75.0 source tree.
They differ from 1.74's dependencies by the addition of
dependencies of the json component, so add a new version
block to FindBoost.
Fixes: #21773
Refactoring in commit 7cc815a2a6 (CUDAToolkit: Detect CUDA SDK that
don't have nvcc, 2020-07-24, v3.19.0-rc1~366^2) accidentally broke
use of the `CUDA_PATH` environment variable.
Fixes: #21740
When a framework is linked to a target by its full path and that
framework is located in one of the implicit framework search directories,
CMake 3.18.5 and earlier discarded that path.
ce2dee9e5b (Xcode: Don't add framework as -framework argument in
linker info list, 2020-09-28) introduced a regression which resulted in
the framework path always being added to the search path even if it
matched one of the implicit search paths. This broke the ability to do
device and simulator builds from the same configured project.
Fixes: #21678
The `-nofor_main` flag was originally added by commit ccdd3e943d (Fix
Intel Fortran SHARED libraries on Linux, 2009-10-27, v2.8.2~915). Since
then, Intel Fortran renamed the option to `-nofor-main` and deprecated
the old name. The new name has been available for a long time, so
we can just switch to it.
Fixes: #21735
