FindGDAL uses GDAL's 'gdal-config' utility to obtain the path to GDAL's library
(on systems identified by CMake's UNIX variable). Older versions formatted this
information like that of dependent libraries:
-L/path/to/gdal/lib -lgdal[suffix]
Newer versions instead provide the full path to the library:
/path/to/gdal/lib/[prefix]gdal[suffix]
FindGDAL now supports both formats. Entries that don't start with '-L' or '-l'
are only considered if they are absolute paths that exist on disk.
Furthermore, libraries are only considered if the name contains 'gdal'
(checked case-insensitively).
e3cd7c1e01 FindOpenMP: Add support for AppleClang compiler
b4c539e651 FindOpenMP: Verify in test source that OMP library is linked
7dd8c7a680 FindOpenMP: Improve inclusion of helper modules
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1812
IBM XL C/C++ for Linux versions 13.1.6 and above no longer define
`__IBMC__` or `__IBMCPP__` by default (see `-qxlcompatmacros`).
Instead `__ibmxl__` now identifies the compiler along with some
related new version macros.
Fixes: #17784
All discovered executables were placed in a component, except for 'jar'.
This forced the use of find_package(Java) without any component
specification. This commit adds 'jar' to the 'Development' component,
because that's what it's used for.
Refactoring in commit v3.11.0-rc1~293^2~4 (Modules: Remove paths set as
global Unix prefixes, 2017-11-20) removed `PATH_SUFFIXES` options that
appeared to be used to cover subdirectories of the `PATHS` options that
were also removed. However, the path suffixes also apply to other
search paths and so should not be removed. Restore them.
Fixes: #17760
Typical Fortran compiler command-line tool names differ on Windows and
non-Windows platforms. Also, the name `ifc` should not be used on
Windows because there is an `ifc.exe` tool in Visual Studio that is
unrelated.
Fixes: #17752
We use `LUA_INCLUDE_PREFIX` for the result of an internal `find_path`
call and unset the cache entry before each use. Unset a plain variable
of this name too in case it was set by project code. Otherwise the
`find_path` call may be skipped and the wrong value used, leading to
errors.
In commit v3.11.0-rc1~466^2 (Compiler/TI: Add support for depfile
generation for Ninja, 2017-10-16) the flag for C++ was added in a
variable with a typo in its name. Fix the spelling.
Issue: #17360
When the path containing the wxLibraries contains a "-L", a "string(REPLACE "-L" ...)
replaces the content and results in a wrong path. The regex fixes this.
FindZLIB accepts various names for zlib (e.g. "z", "zlib", ...) in
various search locations. Before this patch zlib ignored the priority
implied by the search locations and instead prioritized based on the
library name. Consequently ensuring the pick of a zlib from e.g. a
CMAKE_PREFIX_PATH was not possible if it didn't have the highest
priority name ("z").
This unexpected behavior led to bugs in third party projects (e.g.
https://github.com/Microsoft/vcpkg/issues/1939). A common way to
encounter the issue in the wild is on Windows with the popular
Anaconda python distribution which puts a "z.lib" in a lib/
subdirectory reachable from a bin/ path in PATH. From then on cmake
will always pick up this library instead of the one intended by the
user.
This patch adds the NAMES_PER_DIR option to the find_library calls made
by FindZLIB making it search each directory for all names before
considering lower priority directory names resolving these issues.
Brad King