One such badly designed package is the lapack software where those developers
(still as of the latest version, 3.9.0) do not use the NAMESPACE
option to install(EXPORT…) to set, e.g., a LAPACK:: namespace on
the imported lapack, etc., libraries. And even though I successfully
used env CMAKE_PREFIX_PATH=/home/software/lapack/install-3.9.0 to find
the version of lapack that I built myself, I discovered afterward that
target_link_libraries( lapack) linked to the system library lapack
rather than the imported target with that same name (at least for
cmake-3.13.4).
If this lapack issue is a common occurrence for “config” CMake
packaging for other software packages, would CMake developers be
willing to change target_link_libraries to first search for targets
rather than libraries? Or has that already been done for CMake
versions > 3.13.4 with appropriate POLICY change?
But while such issues are being sorted out at the CMake level as
requested above or at the packaging level for individual software
projects such as lapack here is a workaround to overcome this issue for the
lapack case which could easily be generalized for other packaging
efforts with the same issue:
# Try pure config package first.
find_package(LAPACK CONFIG)
if(TARGET lapack)
# Found it. Now do what lapack team should have done which is to
# create the LAPACK::lapack target rather than just the lapack target
# to distinguish it from the lapack library.
# Setting the following property allows creating an alias library with
# the desired LAPACK::lapack name.
set_target_properties(lapack
PROPERTIES
IMPORTED_GLOBAL ON)
add_library(LAPACK::lapack ALIAS lapack)
set(LAPACK_LINKER_FLAGS)
set(LAPACK_LIBRARIES LAPACK::lapack)
else(TARGET lapack)
find_package(LAPACK REQUIRED)
endif(TARGET lapack)
message(STATUS "LAPACK_LINKER_FLAGS = ${LAPACK_LINKER_FLAGS}")
message(STATUS "LAPACK_LIBRARIES = ${LAPACK_LIBRARIES}")