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.
The FASTBuild generator puts source files from different subdirectories
into different `FastbuildObjectListNode` instances. This ensures that
files with the same name will not write to the same object file. A unity
bucket can only contain files from a single `FastbuildObjectListNode`
instance, so a side effect of this logic is that unity buckets can only
contain files in the same subdirectory. This change fixes the problem by
skipping the subdirectory check logic for files with unity enabled.
Fixes: #27457
d284ce2fd6 Initialize character set encoding on program startup
6ec707312d Make character classification locale-independent
ea47c154e5 Make case-dependent operations locale-independent
c81909f842 Merge branch 'upstream-KWSys' into cmake-locale
5a187b69e7 KWSys 2026-02-11 (dcab76ba)
55842d16ac cmFileCommand: Adopt `file://` URL compatibility helper
6fe7acfe1d curl: Build with support for wide-character filesystem APIs on Windows
9a2ebd7f25 Tests: Add RunCMake.string case covering TOLOWER and TOUPPER with UTF-8
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Overchenko <aleksandr9809@gmail.com>
Merge-request: !11647
libarchive uses `nl_langinfo(CODESET)` as the host's encoding to convert
path names to/from the archive's encoding. Since commit cd408d93fd (Add
setlocale() calls around use of libarchive APIs, 2015-02-06, v3.1.3~2^2)
we've set `LC_CTYPE` using a scoped locale around libarchive calls to
avoid affecting character classification in the rest of the program.
We've since updated the rest of our code to be locale-independent.
Replace the scoped locale with a single locale established at program
startup. This is more efficient and avoids mutating global state.
Issue: #27562
6d8ce8b190 VS: Accept Windows 11 SDKs as semantically equivalent to Windows 10 SDKs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11671
6d8ce8b190 VS: Accept Windows 11 SDKs as semantically equivalent to Windows 10 SDKs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11671
Teach CPS import to read the `link_libraries` attribute. We've exported
this for a long time, but apparently the code to read it back was never
implemented. (To be fair, use of this attribute is discouraged.)
Teach CPS export to fill the `dyld_requires` attribute based on the
equivalent of the `IMPORTED_LINK_DEPENDENT_LIBRARIES` CMake property.
(Note that, in practice, I don't believe this can ever contain
non-targets, and CPS does not anyway support the `dyld_libraries`
attribute that those would require at this time.
Issue: #27501
This gathers properties and other details affecting Built Module Interface (BMI)
compatibility for C++ module importers and applies them as necessary to
synthetic targets, which represent a specific module import scenario.
C++ module importers may have specific usage requirements that differ from
other importers of the same module, potentially requiring separate Built Module
Interfaces (BMIs) for compatibility. CMake creates synthetic targets to
generate and link usage-specific BMIs. This change extends CMake's per-importer
BMI generation to native targets in addition to imported targets.
Curl 7.71 added an option to open files on Windows using wide APIs. See
curl commit `ffdddb45d9` (curl_setup: support Unicode functions to open
files on Windows, 2020-01-02, `curl-7_71_0~148`). When enabled, curl's
own narrow APIs expect UTF-8 because that is what their command-line
tool uses internally. See curl commit `9e5669f388` (tool: support
UTF-16 command line on Windows, 2019-04-12, `curl-7_71_0~149`).
Revert our previous workaround from commit e63dcb1378 (Encoding: Use
encoding libcurl expects with file: urls, 2014-11-05, v3.2.0-rc1~420^2)
in favor of passing URLs to curl encoded as UTF-8.