# Woraround to overcome badly designed config packaging with imported target names = library names
**URL:** https://discourse.cmake.org/t/woraround-to-overcome-badly-designed-config-packaging-with-imported-target-names-library-names/893
**Category:** Code
**Created:** [March 31, 2020, 11:18pm UTC](https://discourse.cmake.org/t/woraround-to-overcome-badly-designed-config-packaging-with-imported-target-names-library-names/893 "2020-03-31T23:18:00Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@airwin](https://discourse.cmake.org/u/airwin)
#### Post date: [March 31, 2020, 11:18pm UTC](https://discourse.cmake.org/t/woraround-to-overcome-badly-designed-config-packaging-with-imported-target-names-library-names/893/1 "2020-03-31T23:18:00Z")
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:
```auto
# 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}")
```
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 1, 2020, 4:56am UTC](https://discourse.cmake.org/t/woraround-to-overcome-badly-designed-config-packaging-with-imported-target-names-library-names/893/2 "2020-04-01T04:56:13Z")
Does using `$` work?
> [@airwin](#):
>
> 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?
I don’t think we can change the current behavior without a new policy, but I don’t know how we could write such a policy if we end up going with `-lfoolib` in the current case since the warning would have to be at build time.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [April 1, 2020, 9:04pm UTC](https://discourse.cmake.org/t/woraround-to-overcome-badly-designed-config-packaging-with-imported-target-names-library-names/893/3 "2020-04-01T21:04:59Z")
I thought CMake already uses targets in preference to libraries and that it has been this way for a long time (maybe @brad.king can confirm this) . Perhaps the target you are expecting to be picked up in your `target_link_libraries()` call is not a global target and isn’t in scope at the point you are expecting it to be used? For example, if you use `find_package()` to find something, it creates a local imported target. That target will be visible in the current scope and below, but not in parents or siblings. So if one subdirectory does the `find_package()` call and you try to refer to that target name in a different directory that isn’t that same directory or a child of it, then the target won’t be visible. Linking to the name would result in CMake looking for a target by that name, failing to find one and assuming it refers to the name of an ordinary library to be linked with `-lthename` instead. It looks like you kinda already know this though, given that your example promotes the local imported targets to global so you can create your own ALIAS for it.