Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with CMake's imported targets LAPACK::LAPACK #483

Open
leha-bot opened this issue Feb 8, 2021 · 3 comments · May be fixed by #840
Open

Compatibility with CMake's imported targets LAPACK::LAPACK #483

leha-bot opened this issue Feb 8, 2021 · 3 comments · May be fixed by #840

Comments

@leha-bot
Copy link

leha-bot commented Feb 8, 2021

The upstream CMake has some machinery to find the LAPACK library and it defines the LAPACK::LAPACK imported target.
It would be very convenient if the lapack itself make this imported target
See upstream documentation for package API details and
see this new fancy guide about importing and exporting targets

Thanks for your attention!

@leha-bot
Copy link
Author

leha-bot commented Feb 8, 2021

I also think that it could be implemented via modifying the (lapack-config-install.cmake.in)[https://github.com/Reference-LAPACK/lapack/blob/master/CMAKE/lapack-config-install.cmake.in] by adding this snippet:

add_library(LAPACK::LAPACK UNKNOWN IMPORTED)
target_link_libraries(LAPACK::LAPACK PUBLIC lapack)

but I'm not exactly sure about it. I'll try to check it and make PR if you will be interested in it

@thijssteel
Copy link
Collaborator

Sounds interesting, some notes though:

  • this is the reference implementation of LAPACK, it is usually more appropriate to use other implementations.
  • most of the contributers here have a more mathematical background, so we wouldn't really be able to keep that config up to date if there are changes upstream

@christoph-conrads
Copy link
Contributor

  • this is the reference implementation of LAPACK, it is usually more appropriate to use other implementations.

Usually but in 2016 for example there was still no 2-by-1 CS decomposition in Intel MKL.

  • most of the contributers here have a more mathematical background, so we wouldn't really be able to keep that config up to date if there are changes upstream

CMake can automatically generate the target export. There is hardly any need to maintain it but #488 should be resolved before.

From the top of my head:

include(GNUInstallDirs) # avoid having to bother with `lib`, `lib64` directories
option(BUILD_SHARED_LIBS "Build shared libraries" CACHE ON)
add_library(blas sgemm.f)
add_library(lapack sggqrcs.f)
target_link_libraries(lapack blas)
install(
  TARGET blas
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  EXPORT blas-export
)
install(
  TARGET lapack
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
  EXPORT lapack-export
)
install(
  EXPORT blas-export lapack-export
  DESTINATION ${CMAKE_INSTALL_LIBDIR}/${PROJECT_NAME}-${PROJECTION_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants