Several problems with this feature came up while testing 4.3.0-rc1.
These include both broken stdlib distributions and regressions in our
implementation of the feature since CMake 4.2.
Revert commit 70c1f0f43d (Experimental: Remove import std experimental
gate, 2026-02-04, v4.3.0-rc1~61^2) except for its incidental fixes.
Remove the 4.3 release notes related to `import std`.
Rotate the experimental gate's UUID.
Issue: #27426
Issue: #27597
Issue: #27626
Issue: #27635
The format example for CMAKE_INSTALL_EXPORTS_AS_PACKAGE_INFO is quite
long and, in its prior state, was likely to force a line wrap before it,
which could lead to non-optimal spacing of the preceding line. As there
is no easy way to break in the middle of the example, instead break it
out into a separate element.
Remove basic CPS import and export from 'experimental' status. Update
documentation and tests accordingly.
Note that mapped exports (CMAKE_EXPERIMENTAL_MAPPED_PACKAGE_INFO) are
still experimental.
Previously, `CMAKE_<LANG>_LINK_FLAGS` was an undocumented variable used
for linking executables only. Re-spell that variable mirroring the
existing spellings for shared and module libraries, and add policy
CMP0210 to preserve compatibility.
Then, repurpose `CMAKE_<LANG>_LINK_FLAGS` to provide a variable to be
used for per-language link flags for all target types, along with a
per-configuration variant. These are added to the `<LINK_FLAGS>` rule
placeholder in the generators.
Fixes: #21934
Relates: #25620
Co-authored-by: Brad King <brad.king@kitware.com>
Improve the wording on the behavior of the per-configuration variants
of `CMAKE_*_LINKER_FLAGS`. In particular, note that these variables
only apply to the specified build configuration, and replace the
ambiguous reference to `CMAKE_C_FLAGS_*` with a precise description.
Clarify that the "default" variants of these variables apply for all
build configurations.
Add links between pages for the default and per-configuration variables.
Add support for PRIVATE header sets, analogous to the existing
INTERFACE header sets support. A key difference between the two is
the way they handle build and usage requirements. INTERFACE
header sets rely on the original target's INTERFACE, whereas PRIVATE
header sets copy across various properties from the original target.
Generated files need special handling for PRIVATE header sets.
Add a dependency on the original target to the verification target to
ensure such generated files will exist.
Fixes: #23448
Add the ability to generate CPS package information when install(EXPORT)
is used. This relies on additional information to be passed to CMake,
and is intended as a way of getting CPS out of existing projects without
needing to make changes to the projects' CMakeLists.txt. (Particularly,
this feature is intended for package distributors, not project authors.)
When setting the installation prefix at the installation phase
(`cmake --install`) using the `--prefix` option, the GNU special cases
aren't applicable. This also adds a small clarification when to use the
`--prefix` option at the installation phase.
Briefly mentioned also the CMake presets installDir field,
the CPACK_PACKAGING_INSTALL_PREFIX variable, and the $<INSTALL_PREFIX>
generator expression so user has a better overview.
Fixes#27343Fixes#26338
Add `CPACK_ARCHIVE_UID` and `CPACK_ARCHIVE_GID` options.
Add a policy to change the default to 0/0 to enable ownership
by root if unpacking as root.
Fixes: #12901
Xcode by default targets the SDK's macOS version rather than the host's
macOS version. In commit 7b19531291 (macOS: Do not pass any
SDK/-isysroot to compilers by default, 2024-11-06, v4.0.0-rc1~511^2) we
reverted commit 24aafbde11 (Xcode: Adjust deployment target SDK version
to host version, 2015-10-11, v3.4.0-rc2~6^2), but it is still needed for
Xcode. Restore the behavior so binaries run on the host by default.
Fixes: #27309
Intel oneAPI distributions no longer include the `ifort` compiler, but
its Visual Studio Integration defaults to `ifort` if `ifx` is not
explicitly specified in the `.vfproj` file. We cannot change the
default Fortran compiler in VS 17 and older, but since the VS 18
generator is new, we can establish `ifx` as its default. This
establishes working defaults on new versions of VS and oneAPI while
retaining existing behavior on older versions.
Issue: #26415
47c784ba8a Help: Add release note for Visual Studio 18 2026 generator
cd46d8ec84 Merge branch 'backport-vs2026' into vs2026
3392b371e2 VS: Add Visual Studio 18 2026 generator
7f0883ac04 VS: Remove unused generator code
6f0d245083 VS: Fix `/dynamicdeopt` flag table entry order for v145 toolset
398ce8af72 VS: Remove `/guard:cf` from v145 link flag table
5c9085d876 VS: Remove `/MERGE` from v145 link flag table
fe5c78310c VS: Map the link `/debug` flag for v145 toolset
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11168
85e536b5eb gitlab-ci: test `CMAKE_CXX_STDLIB_MODULES_JSON` in CI
42621a232b Tests/CXXModules: add a label
2f101b2c8c Tests/CXXModules: support testing with custom stdlib json locations
6c178a4ae3 Tests/RunCMake: add newlines in CXXModules options
2b85541e39 cxximportstd: support setting the `import std` metadata location
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11175
Some deployments may not be able to discover the metadata file reliably
(e.g., custom `clang` builds on macOS while using the SDK's stdlib or
distribution bugs). Allow users to force the location so that
compiler-driven detection doesn't have to bend over backwards for
unforeseen bugs.
Projects which ship object files as artifacts may want to control the
object names as much as possible. Support setting explicit object names
as source file properties to support such use cases.
CMake historically has forced an `objects[-<CONFIG>]/<TARGET_NAME>`
subdirectory under an `OBJECT` library installation's `OBJECTS
DESTINATION` which may be unwanted. Support skipping this component
with a target property.
