CMake merge requestshttps://gitlab.kitware.com/cmake/cmake/-/merge_requests2021-08-19T15:22:22-04:00https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5903VS: Fix '-T version=14.28' under VS 16.92021-08-19T15:22:22-04:00Brad KingVS: Fix '-T version=14.28' under VS 16.9CMake 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...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.
Also accept and translate '-T version=' values with three components.
The `vcvarsall` option `-vcvars_ver=` accepts a three component version,
so accept this format for VS toolset selection too.
Fixes: #21922
Backport: release3.19.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/5899Xcode: Restore support for spaces in framework names2021-03-15T12:13:36-04:00Brad KingXcode: Restore support for spaces in framework namesIn !5216 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
Backport: release:HEAD~1^2In !5216 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
Backport: release:HEAD~1^23.19.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/5897Cray: Enable Cray compiler wrapper detection on all platforms2021-03-15T12:10:34-04:00Justin LaPollaCray: Enable Cray compiler wrapper detection on all platformsCustomer reported problems detecting the Cray compiler wrapper on their
Apollo80 system. We were checking for the `__CRAYXC` and `__CRAYXE`
predefined macros. These macros reflect the platform that the compiler
wrapper is running on, i.e...Customer reported problems detecting the Cray compiler wrapper on their
Apollo80 system. We 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. Naturally,
this didn't work on Apollo80.
This commit uses 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
Backport: release3.19.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/5889Revert "Cray: Fix Cray compiler detection on new platforms"2021-03-15T12:10:32-04:00Brad KingRevert "Cray: Fix Cray compiler detection on new platforms"The justification in !5561 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 ...The justification in !5561 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
Backport: release3.19.7Brad KingBrad King