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).*/`.
The point is that `cmFileListBlahBlahGenerator` actually "generate"
directory names and never files.
The `cmBlahBlahStringGenerators` produce paths in fact. Ok, paths
nowadays are also strings but...
The `cmFileListGeneratorProject` and `cmFileListGeneratorMacProject`
was look very similar 'cept few lines.
Now they have a base class and the generator-specific logic has moved
to overrides.
Original code had path generators built at run-time using a linked list
of dynamically allocated nodes each of which was responsible to generate
a path segment.
However, the combination of used generators is totally well known at
compile time.
The `cmFindPackageFileList` instances always constructed w/ the only
parameter. The boolean flag is always `true` (default value).
Also, `cmFindPackageCommand::InitialPass` adds an empty string
to the `cmFindPackageCommand::SearchPathSuffixes` vector. Meaning
that `cmFindPackageCommand::CheckDirectory()` gonna be called for
the suffix-less path, so `cmFindPackageFileList::Visit` may call
only `cmFindPackageCommand::SearchDirectory` and get the same result.
They are unique by design. I.e., when the algorithm iterates over
args doing only one push per iteration indices gonna be unique ;-)
So, no need for `std::set` here.
