Adds a parser and serializer for the EcoStd Module Metadata format
RFC: https://github.com/ecostd/rfcs/pull/3
This adapts the existing experimental support for import std; to use
the new parser. The CMAKE_CXX_STDLIB_MODULES_JSON is now the canonical
variable for controlling how CMake discovers the stdlib module metadata,
and is used directly by compiler detection.
Toolchains can still override the __CMAKE::CXX## targets if they wish,
either in conjunction with CMAKE_CXX_STDLIB_MODULE_JSON or not. It is
possible to disable automatic detection of
CMAKE_CXX_STDLIB_MODULE_JSON by setting it to the empty string.
When available, the CMAKE_CXX_STDLIB_MODULE_JSON will be used to create
all requested C++ stdlibs which do not already have targets.
Extend commit e6aa7742b0 (VS: Generate .slnx files for VS 2026,
2025-09-17, v4.2.0-rc1~151^2) to add the `Type=` attribute on SLNX
`<Project>` elements.
Fixes: #27392
fd7e305097 GenEx: Add $<STRING> generator expression
7564cbae12 GenEx: add new expressions for string comparisons
dab5e6ebb1 introduce cm::CMakeString class as helper for string() command
34c0c7754f cmString: add methods append and insert
ab60f1a010 Extend usage for cm::string_view for more flexibility
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11382
At the time of commit e6aa7742b0 (VS: Generate .slnx files for VS 2026,
2025-09-17, v4.2.0-rc1~151^2), the VS 18 Insiders edition did not offer
support for specifying a default startup project in `.slnx` files.
This has since been added, so use it.
Fixes: #27387
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
Print the system error message in case of failure when calling
`CopyFileAlways`, `CopyFileIfDifferent`, `CopyFileIfNewer`,
`CopyADirectory` and `MakeDirectory`.
Remove unnecessary `cmSystemTools` wrappers for `CopyFileIfNewer` and
`CopyADirectory`.
Fixes: #18276
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.)
40b093649b cmake: Avoid calling GetCMakeListFile with empty directory
f6b3ba5f55 CMP0198: Maintain CMAKE_PARENT_LIST_FILE only when configuring projects
3593aa59ef cmake: Replace working mode with role
accfa7fa81 cmake: Infer command failure action from role
e290d4f2a3 cmake: Infer command set from role
bfaaec6179 cmake --workflow: Convert implementation to internal role
ea5d04975e cmake --build: Convert implementation to internal role
0b83750e14 cmake: Clarify name of role of internal instances
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !11395
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've
occasionally observed immediate timeouts on processes that take longer
than the timeout to start, even though we only start the timer after the
child processes start. The problem is that:
* `uv_loop_init` initializes `uv_loop_t`'s cached "now" time.
* Starting processes takes time but does not update the "now" time.
* `uv_timer_start` computes expiry relative the cached "now" time,
so short timers may be expired as soon as they are started.
* `uv_run` invokes expired timer callbacks before polling for I/O
or process completion, so we "timeout" immediately.
Fix this by updating the cached "now" time via `uv_update_time` just
before starting timers. This is needed only for timers that start
before the `uv_run` event loop. Update our `uv_timer_ptr` wrapper
to make all callers consider the choice when calling `start()`.
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
fa4bed7844 cmPackageInfoReader: Don't crash if input is malformed
be99a82eee cmPackageInfoReader: Just use std::string
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11390
