GitLab

Co-Authored-by: Brad King <brad.king@kitware.com>

Revert commit 8f1e607e (Help: Document JSON comment support in
cmake-presets(7), 2021-02-18).  The support for comments was a mistake
when the feature was implemented in 3.19, and is being removed.

The main `cmake --preset` argument for configure presets supports both
forms, so support it for `ctest --preset` too.

Fixes: #21855

The main `cmake --preset` argument for configure presets supports both
forms, so support it for `cmake --build --preset` too.

Issue: #21855

This form already works.  Document it and add tests.

Issue: #21855

Co-Author: Brad King <brad.king@kitware.com>

Suggested-by: Michael Hirsch

Fixes: #21835

Version 2 is required for build and test presets.

Fixes: #21829

This was accidentally included after discussion in #21391 had decided to
leave it out.  It was never included in a release.

Issue: #21391

Document that one can call `set_property` directly instead.

This makes them linkable, indexed, and enables cross-references.

These two fields share common documentation and so should be a single
entry in the definition list.

Fixes: #21642

Cross-reference it from the main `configurePresets` field.
This removes an extra layer of indentation and makes the
section linkable.

Also cross-reference it from the prose.

The entire "Format" section had an extra 2 spaces of indentation.

Co-Authored-By: Craig Scott <craig.scott@crascit.com>

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

Fixes: #21268

Fixes: #20682

Co-Author: Brad King <brad.king@kitware.com>

Fixes: #21477

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.

Since commit b6c60f14 (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

Fixes #21559

See justification in the policy documentation.

Closes: #17842

The module has been deprecated since commit 306a1ba9
(Modules/Documentation: remove, 2020-04-16, v3.18.0-rc1~290^2).