Implement finding dependencies of CPS packages. This is done by setting
up additional `cmFindPackageCommand` instances which are used to look
for a parent package's dependencies.
A root path like `/` or `c:/` needs to end in a slash. Revise our
prefix search logic to maintain a trailing slash instead of removing one
just to add it again.
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.
e2a6416622 find_package: Refactor in support of recursion
bd542748af find_package: Use map::emplace instead of make_pair
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !10054
Tweak a helper function to avoid an implicit cast from unsigned to
signed. This is hardly the only -Wsign-conversion we are tripping, but
cmFindPackage is now free of such.
Separate argument handling and actual operation of the find_package
command into separate methods. This is preparatory to adding improved
support for transitive dependencies and will allow nested calls to be
set up using structured data types, rather than having to perform all
communication via a constructed argument list.
As a consequence, the sets of required and optional components, as well
as the component list string, are now members rather than local
variables. This also allows us to drop some parameters and simplify how
we set the variables indicating which components are required.
Replace map::insert(make_pair(...) with map::emplace(...). This should
be slightly more efficient, but also removes one of only two uses of
std::pair. (Upcoming changes are going to remove the other, which will
let us drop use of <utility>.)
Some error messages (Windows registry related) of the `find_xxx` and
`cmake_host_system_information` commands, reported keywords in quotes,
while most commands did not.
Change cmDirectoryListGenerator::Names to be a pointer rather than a
reference wrapper. This allows it to be a null pointer, which allows
cmAnyDirectoryListGenerator to pass a nullptr rather than needing to
construct and hold an empty list just to satisfy the reference being
non-null. Importantly, it also make it more obvious that anyone
constructing a cmDirectoryListGenerator or subcless thereof needs to
pass something that isn't going to immediately go out of scope.
Tweak `find_package` to not compare an already-specified `<name>_DIR`
against the set of ignored paths. This is a minor behavior change in
that, if a previously found package is in a location that is NEWLY
ignored (i.e. because the user modified the ignored paths since the
previous run of CMake), we won't throw out the old result. However, it
also means that a user specifying `<name>_DIR` takes precedence over the
set of ignored paths, which seems like the desired behavior.
Note that the current behavior was introduced in commit 11f97d1968
(find_package: Refactor CMAKE_[SYSTEM_]IGNORE_PATH, 2022-01-28,
v3.23.0-rc1~31^2) and appears to have been unintentional.
Add cmAnyDirectoryListGenerator, which matches any directory but also
sorts matches in the same manner as cmProjectDirectoryListGenerator.
Modify SearchFrameworkPrefix to use this, in combination with a literal
path (cmAppendPathSegmentGenerator), instead of cmFileListGeneratorGlob
(which is removed, as it is no longer used). This improves the
consistency of when sorting is available.
This uses cmDirectoryListGenerator's new ability to match anything, as
mentioned in the previous commit.
Modify cmDirectoryListGenerator to support exact matching as well as
'starts-with' matching. The latter is used to implement '<name>*' search
paths, but cmDirectoryListGenerator is also used for '<name><suffix>'
matching (via cmMacProjectDirectoryListGenerator, mainly for macOS
paths), which resulted in the latter actually matching '<name><suffix>*'
even though that is not documented and unlikely to be useful.
This also adds the ability for cmDirectoryListGenerator to match
anything (by giving an empty list of names), which isn't in use yet, but
which we will use in the future.
find_package()'s debug mode provides information about which
prefixes are searched, but not which roots are prepended to each
prefix. Display this information if debugging is enabled.
Upstream Boost 1.70 and above provide a proper `BoostConfig.cmake`
package configuration file. Packages for all major distros now
provide it in at least one LTS release. Add a policy to pretend
that the `FindBoost` module does not exist so that projects calling
`find_package(Boost)` use the upstream package directly.
Closes: #19402
41f4e1c457 CMakePackageConfigHelpers: Document PACKAGE_PREFIX_DIR for public use
c5231ba29e find_package: Save/restore PACKAGE_PREFIX_DIR
8ac7958e3a generate_apple_*_selection_file: Save/restore PACKAGE_PREFIX_DIR
bf88879f1f generate_apple_architecture_selection_file: Avoid early returns
a4ac2c92f4 Help: Add missing section heading for apple architecture selection
b7fcc44be9 Help: Fix CMakePackageConfigHelpers typos, grammar and formatting
f1cacaa830 Tests/RunCMake/CMakePackage: Define variable closer to where it is used
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9430
Package configuration files generated by `configure_package_config_file`
set this variable in `@PACKAGE_INIT@` and then use it later. There may
be intervening calls to `find_package`, e.g., via `find_dependency`.
If the loaded package also used `configure_package_config_file`, it
may change the value of `PACKAGE_PREFIX_DIR`. Explicitly save and
restore the value to avoid this.
Fixes: #25827
`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 12.
The `FindPythonInterp` and `FindPythonLibs` modules have been deprecated
since CMake 3.12. Add a policy to pretend they do not exist in order to
encourage projects to port to `FindPython` or `FindPython{2,3}`.
The `FindCUDA` module has been deprecated since CMake 3.10.
Add a policy to pretend it doesn't exist in order to encourage
projects to port away from it.
Extend commit eb35d8884b (find_package: Use PackageName_ROOT variables
as search prefixes, 2018-03-15, v3.12.0-rc1~349^2) to also check
upper-case `<PACKAGENAME>_ROOT` variables. Add policy `CMP0144` to
enable the behavior in a compatible way.
Fixes: #24403
Extend the LCC warning suppression from commit 08e7fb3cfa
(cmFindPackageCommand: Compile-time path generator expressions,
2022-07-05, v3.25.0-rc1~361^2~5) to cover a new number for the
same warning, now produced by LCC 1.26.15.
The `PREFIX/(Foo|foo|FOO).*/(cmake|CMake)/(Foo|foo|FOO).*/` search
path is the similar to the one already exists
`PREFIX/(Foo|foo|FOO).*/(lib/ARCH|lib*|share)/cmake/(Foo|foo|FOO).*/`.
