Since commit ffc06c1239 (Teach find_(library|file|path) to get prefixes
from PATH, 2015-02-18, v3.3.0-rc1~430^2) we search in `<prefix>/include`
and `<prefix>/lib` directories for prefixes with `bin` directories in
the `PATH` environment variable. The motivation was to search the
installation prefixes of MSYS and MinGW development environments
automatically.
This behavior can search undesired prefixes that happen to be in the
`PATH` for unrelated reasons. It was reverted for non-Windows hosts
within a year by commit b30b32a493 (Drop find_(library|file|path)
prefixes from PATH on non-Windows, 2016-05-09, v3.6.0-rc1~82^2) but was
kept on Windows hosts to support its motivating use case. However,
similar problems have since been observed on Windows. For example,
commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the
'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2) was primarily
due to undesired discovery of libraries in `PATH`-derived prefixes.
Since commit 5e5132e1b1 (MinGW: Search for packages in standard MSYSTEM
environment prefixes, 2023-09-11) we search MSYS and MinGW environments'
prefixes explicitly, so `PATH`-derived prefixes are no longer needed for
the original motivating use case.
Fixes: #24216
The documentation of the find-commands was pointing to the
cmake variables CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH etc.
also in the section for environment variables. Now they point
to the documentation for the respective environment variables.
Documentation updates in commit 02f527c66a (Find: Provide global
controls for the `NO_[]_PATH` call options, 2019-06-12,
v3.16.0-rc1~541^2) accidentally switched the `find_library`
documentation to mention `INCLUDE` where it should be `LIB`.
While at it, update `find_file` and `find_path` to mention
`INCLUDE` and `PATH` in the order they are considered.
This feature was originally added by commit v3.9.0-rc1~71^2~2 (find_*:
Add a new PackageRoot search path group, 2017-05-03) and documented by
commit v3.9.0-rc1~71^2 (find_*: Add docs for PackageRoot search path
group, 2017-05-03). However, we had to disable the feature and remove
the documentation in commit v3.9.1~2^2 (find_*: Disable the PACKAGE_ROOT
search path group for CMake 3.9, 2017-08-08) due to breaking projects
that used `PackageName_ROOT` variables themselves.
Add policy `CMP0074` to restore the `PackageName_ROOT` variable behavior
in a compatible way. Also revise the stack of root paths to store the
paths themselves rather than the package names. This way the policy can
be considered at the `find_package` call site instead of individual
`find_` calls inside a find module.
Co-Author: Chuck Atkins <chuck.atkins@kitware.com>
Issue: #17144
Disable the feature added by commit v3.9.0-rc1~71^2~2 (find_*: Add a new
PackageRoot search path group, 2017-05-03) and remove documentation
added by commit v3.9.0-rc1~71^2 (find_*: Add docs for PackageRoot search
path group, 2017-05-03). Unfortunately the name `<pkg>_ROOT` may
already be set by projects for their own incompatible purposes. Disable
the behavior change for now to fix the regression for CMake 3.9. We can
restore it later with a policy.
In order to keep the implementation and tests working, add an
undocumented variable we can use in the tests to enable the behavior
before the policy is introduced.
Fixes: #17144
Detect x32-abi through CMakeCompilerABI infrastruture and use this
information at runtime to determine the correct library paths with
`FIND_LIBRARY_USE_LIBX32_PATHS`.
Fixes: #15994
Add a new `CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable to allow use
of a custom suffix on `lib` directory names. This is a more general
option than that added by commit v3.7.0-rc1~504^2 (Teach find_library
and find_package to search lib32 paths, 2016-06-10). It allows the find
path to be more deterministic on custom setups.
See discussion in #10287 and #15994.
Add a ``FIND_LIBRARY_USE_LIB32_PATHS`` global property analogous to the
``FIND_LIBRARY_USE_LIB64_PATHS`` property. This helps find commands on
multilib systems that use ``lib32`` directories and either do not have
``lib`` symlinks or point ``lib`` to ``lib64``.
Since commit v3.3.0-rc1~430^2 (Teach find_(library|file|path) to get
prefixes from PATH, 2015-02-18) we search in <prefix>/include and
<prefix>/lib directories for prefixes with bin directories in the PATH
environment variable. The motivation was to support MSYS, MinGW and
similar Windows platforms in their default environments automatically.
At the time this behavior was thought to be worthwhile in general.
Suggested-by: Chuck Atkins <chuck.atkins@kitware.com>
The find_package command already knows how to compute installation
prefixes from PATH. Use the same approach to establish prefixes for
find_library, find_file, and find_path to use to look in directories
like "<prefix>/lib[/<arch>]" and "<prefix>/include" for libraries and
headers. This will reduce the amount of configuration end users need to
do to establish a work environment rooted under a specific prefix.
These documents were represented in the builtin documentation using a
common starting point with placeholders substituted by each command.
Convert them back to this approach using the reStructuredText include
directive and substitutions to avoid duplication.
