When targeting the GNU ABI, we consider `.a` libraries first but also
accept `.lib`. For symmetry, when targeting the MSVC ABI, we now
consider `.lib` first but also accept `.a`.
This adds support for meson-generated static libraries, which are named
with the pattern `lib${foo}.a`:
* https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
Note that this was previously attempted by
* commit be848a71b0 (MSVC: Teach find_library to consider the 'libfoo.a'
naming convention, 2022-09-19, v3.25.0-rc1~111^2)
but was reverted by
* commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the
'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2)
due to problems finding GNU ABI libraries in PATH-derived prefixes.
Since then,
* commit 0a81110b84 (find_(library|file|path): Drop PATH-derived search
prefixes, 2023-09-14, v3.28.0-rc1~91^2)
removed the problematic search paths, so we can restore this change.
Fixes: #23975
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.21 and below to encourage projects to port
away from setting policies to OLD.
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
MSYS2 and similar MinGW/MSYS distributions define development
environments with a `MSYSTEM` environment variable. Each such
environment has a documented installation prefix for its packages,
often provided by a `MSYSTEM_PREFIX` environment variable.
Since commit 84a25fc263 (cmake_host_system_information: Add
MSYSTEM_PREFIX query, 2023-09-08) we can look up this prefix.
Add `$MSYSTEM_PREFIX/local` and `$MSYSTEM_PREFIX` to our system search
prefixes when targeting MinGW under `MSYSTEM` environments. This is
their equivalent to `/usr/local` and `/usr`, which we search by default
on UNIX systems.
Issue: #24216
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
Clear $ENV{CMAKE_PREFIX_PATH} in several RunCMake.find_library tests
because on Windows, a CMAKE_PREFIX_PATH with two consecutive
semicolons causes a library to be found when it should not be.
None of the updated tests expect CMAKE_PREFIX_PATH from the environment
to influence the test, so clear the variable entirely to guarantee it
will not affect the test.
Fixes: #23111
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Add a `--debug-find-pkg=` option to debug find calls for specific
packages.
Add a `--debug-find-var=` option to debug find calls for specific
return variables.
Fixes: #21880
This aligns `find_library` with the documentation that states it
can be called from script mode. This is done by infering the
proper prefix and suffix values when `find_library` is called
when the `CMAKE_FIND_LIBRARY*` are not set. This also means that
`find_library` won't produce obscure error messages about unset
definitions.
Fixes: #22027
Refactoring in commit 6b85166920 (ENH: Refactor find_library search
logic, 2008-09-22, v2.8.0~1665) dropped a call to `FileExists` on the
path under the assumption that the presence of a file in a directory
listing means it exists. However, dropping that also dropped a check
that verifies the file is readable. Restore the `FileExists` call to
ensure that we only find readable libraries.
In the same spirit as the REQUIRED keyword on find_package, this will
stop cmake execution with an error on a failed find_program, find_file,
find_path or find_library.
Teach the find_package, find_library, find_program, find_path, and
find_file commands to print debug log messages when enabled by the
`--debug-find` command-line option or `CMAKE_FIND_DEBUG_MODE` variable.
The `FIND_LIBRARY_USE_LIB<arch>_PATHS` global properties ask
`find_library` to look in `lib<arch>` directories automatically before
corresponding `lib` directories. However, if `lib<arch>` is just a
symlink to `lib` (or vice-versa) then we should skip adding the
`lib<arch>` path. Such symlinks typically only exist to satisfy
software that expects the `lib<arch>` path to be available.
Fixes: #16687
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.
We use cmGlobalGenerator::GetDirectoryContent to avoid repeating
directory listings. However, GetDirectoryContent loads content from
disk at most once. This breaks find_library calls that occur when disk
content has changed since preceding find_library calls.
Teach cmGlobalGenerator::GetDirectoryContent to save the directory
modification time when content is loaded and re-load content if it
changes.
Create a RunCMake.find_library test with a case covering this.
Brad King