Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.
6679 Discussions

Suggestions for improved MKLConfig.cmake

fanselm
New Contributor I
262 Views

We've have moved our dependency management to the Conan package manager system. A major hurdle was making a package for MKL and getting it to work well with typical CMake build systems and its find_package utility. We were therefore happily surprised when we noticed that newer MKL versions now ship an MKLConfig.cmake. However it has some shortcomings as also noted in this question: https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/MKLConfig-cmake-is-great-but-should-... It's nice that you are addressing those issues, here are some more for your consideration:

  • Ensure that each library target has the IMPORTED_SONAME property set, otherwise cmake will link libraries with their absolute path which ld will hardcode if the .so file does not actually specify the SONAME ELF property (which was the case in older MKL versions)
  • Use package components for different additional libraries like CORE, BLACS, ScaLAPACK, CDFT, PARDISO, FFTW, ...,
  • Each component should have an alias target e.g. MKL::CORE, MKL::BLACS, MKL::ScaLAPACK. It is common that big software packages (e.g. scientific python frameworks) have multiple libraries, where some just use mkl_core and some need e.g. scalapack. One should not need to link blacs and scalapack into every library in your project.
  • Remove the ENABLE_BLACS ENABLE_SCALAPACK, ENABLE_CDFT, etc, options as they are no longer needed when using components and multiple alias targets.
  • Ensure that libraries have their INTERFACE_INCLUDE_DIRECTORIES property set. Currently the documentation in MKLConfig.cmake states that MKL::mkl_core has this property set, but that is wrong - only the MKL::MKL target has any include directories set, meaning that individual library targets are unusable
  • Remember to include the FFTW header directory somewhere, either by adding its path to the mkl_core include directories or by making a separate FFTW target.
  • Have package managers like vcpkg and Conan in mind - it should be possible to easily create a package with MKL that can use the shipped MKLConfig.cmake or have the package manager replicate this. Package managers are the future of C/C++ development and their use will only become more and more widespread.

Additional note: Can highly recommend the book https://crascit.com/professional-cmake/ Sadly the official CMake documentation is rather missing, especially on how to practically create and use packages as well as what the modern best practices are.

Thanks again for making a fantastic math library freely available!

2 Replies
Viraj_M_Intel
Employee
216 Views

Thank you @fanselm for the excellent suggestions. We are constantly trying to improve our product and the customer experience, and your feedback is of great help and importance. I have notified my team about the feedback and we will address it as soon as we can.

If you have any other requests, please feel free to reach out.

ShanmukhS_Intel
Moderator
182 Views

Hi fanselm,

 

Thank you for sharing your valuable suggestions. We would like to inform you that we are considering the same and closing the thread for now, any further interactions would be considered community only.

 

Best Regards,

Shanmukh.SS

 

Reply