Implements the generator expression $<PATH:MATIVE_PATH> which convert
path(s) into a native format with platform-specific slashes (``\`` on
Windows hosts and ``/`` elsewhere).
Fixes: #26515
Change path handling in cmPackageInfoReader to also handle relative
paths (and to convert paths to UNIX slashes). In order to facilitate
(read: minimize) parameter passing, several formerly free functions have
been made into member functions. Also, remove some unused parameters.
Implement logic (partly adapted from the 2023 proof-of-concept) to
actually parse CPS files and generate imported targets. Implement logic
to locate and load supplemental files. Adjust prefix handling to require
that the CPS file provides sufficient information to translate the
prefix placeholder into a meaningful path. (Note that this corresponds
to a change in the specification.)
Add a helper class to read CPS files. Use this to teach find_package how
to consider and accept .cps files in its search. (Note that no version
testing is performed at this time.) Add a simple test that we can find a
package from a .cps file and correctly extract the version information.
Note that this doesn't actually import anything from CPS yet.
Teach find_package to search CPS search paths, and to look for CPS file
names. Modify the set of file names to also include the file type (CPS
or CMake-script). Modify the search function to allow specifying which
file type(s) to consider.
During full path search, each possible path is searched for only one of
the two possible file types. However, subsequent runs, or when
considering a user-specified path (<name>_DIR), CMake will look for both
file types.
Note that this only adds the new path search logic as described above;
CMake does not yet know how to read CPS files, and there is a high
likelihood that Bad Things will happen if it tries. However, this seemed
like a good place to checkpoint.
854eba0c53 target_sources: Improve error message for CXX_MODULES on INTERFACE libraries
cd179e7560 Tests/RunCMake/CXXModules: Rename FileSetModules cases to be more specific
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !10090
We support non-compiled `SOURCES` on `INTERFACE` libraries, and also
support `CXX_MODULES` on *imported* `INTERFACE` libraries (via synthetic
targets that compile module interface units). However, we do not
support `CXX_MODULES` on non-imported `INTERFACE` libraries because
there is no place to hold module interface unit's object files for their
module initializers. Previously this was not explicitly rejected, and
so was diagnosed only by "CMake Internal Error" messages due to
assumption violations in the implementation.
Fixes: #26524
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
The `install(RUNTIME_DEPENDENCY_SET)` form processes its arguments in a
slightly different way to other forms of the command. It handles the
`POST_...`, `PRE_...` and `DIRECTORIES` keywords separately. These
keywords are not visible to the first layer of keyword processing, so
they don't terminate multi-value keyword value parsing.
Before commit 6a1fac1450 (install: Normalize DESTINATION paths,
2024-09-18, v3.31.0-rc1~73^2), the `DESTINATION` keyword was handled as
a simple string value. That commit changed it to use a function so it
could process the value before storing it, but the function returned the
wrong value. This meant it was treated as a multi-value keyword instead
of a single-value keyword.
Fixes: #26512
In commit 197cb419d1 (add_custom_command: Add CODEGEN support,
2024-05-27, v3.31.0-rc1~394^2) we accidentally left out the global
`codegen` target's dependencies on the per-directory `codegen` targets.
Add them for parity with the `all` target.
Fixes: #26517
4de5ef45f0 ci: Enable Swift tests in Ninja Multi-Config job on Windows
e1d635e71c Swift: Expand generator expressions in Swift_MODULE_DIRECTORY
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10062
Brad King