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

Merge-request: !5897

Justin LaPolla authored 4 years ago and Brad King committed 4 years ago

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

Merge-request: !5899

In commit ce2dee9e (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

Merge-request: !5889

The justification in commit 9ee4a428 (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

Merge-request: !5853

Kyle Edwards authored 4 years ago and Brad King committed 4 years ago

Fixes: #21858

Merge-request: !5850

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.

Merge-request: !5826

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

Merge-request: !5816

Marc Chevrier authored 4 years ago and Brad King committed 4 years ago

Fixes: #21817

Merge-request: !5811

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

2fc5e5db Clang: Use -imsvc for system include only with MSVC-like front-end

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Thomas Bernard <thomas@famillebernardgouriou.fr>
Merge-request: !5792

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

33fa015b CTest: Restore running dashboard client Test step with modified files

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5791

In commit bb61c2d0 (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 6a6f1d1e (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

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

eafe740e FindXCTest: Fix output directory for test bundle with new build system

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5786

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

0110aa01 IOS_INSTALL_COMBINED: Support Xcode 12 (command line only)

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5785

Yauheni Khnykin authored 4 years ago and Craig Scott committed 4 years ago

The output directory was still correct for macOS with the new build system,
but not for iOS.

Fixes: #20662

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

a8b41e2c LexerParser: Do not override existing _POSIX_C_SOURCE definition
82cfeeb4 Merge branch 'backport-3.18-ci-wix-download' into release-3.18

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5776

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: #21282
Fixes: #20023

Merge-request: !5776

In commit f034b0f6 (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.

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

c40e81ce Help: Restore docs that find_library considers LIB, not INCLUDE

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5772

Documentation updates in commit 02f527c6 (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.

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

82930647 FindBoost: Add support for Boost 1.75

Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5768

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

5389bb42 Xcode: Don't hard-code SDK-provided implicit framework search paths
df08f8df cmComputeLinkInformation: Fix misspelt private variable name
375b307b 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

Brad King authored 4 years ago and Kitware Robot committed 4 years ago

4ea6d3c3 FindCUDAToolkit: Restore use of CUDA_PATH environment variable

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Raul Tambre <raul@tambre.ee>
Merge-request: !5761

Robert Maynard authored 4 years ago and Brad King committed 4 years ago

Refactoring in commit 7cc815a2 (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