2

I am working on a header-only C++11 library which uses modern CMake. By "modern," I mean not only using CMake v3.0+ but also trying to use as much as possible the best practices in Daniel Pfeifer's talk.

I have done some research on my question, but the answers are mostly regarding modifying the LINK_FLAGS directly in the global level, which I do not want to have. Right now, in my project, I require a minimum version of 3.9.0 of CMake because of some features I am using.

My question is about whether/how to add LINK_FLAGS coming from two of my dependencies: BLAS and LAPACK. Basically, I have the following excerpt from my CMakeLists.txt file:

cmake_minimum_required(VERSION 3.9.0)

project(polo VERSION 1.0.0 LANGUAGES C CXX)

find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)

add_library(polo INTERFACE)
add_library(polo::polo ALIAS polo)

target_compile_features(polo INTERFACE cxx_std_11)

target_include_directories(polo
  INTERFACE
    $<BUILD_INTERFACE:${polo_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)

target_link_libraries(polo
  INTERFACE
    ${BLAS_LIBRARIES}
    ${LAPACK_LIBRARIES}
)

set_property(
  TARGET
    polo
  PROPERTY LINK_FLAGS
    ${BLAS_LINKER_FLAGS}
    ${LAPACK_LINKER_FLAGS}
)

As far as I can understand from documentations of the FindBLAS and FindLAPACK modules, I need to inform my users at least about {BLAS,LAPACK}_LIBRARIES and {BLAS,LAPACK}_LINKER_FLAGS. For the former, I think I have handled the issue properly. However, for the latter, I need to use either set_target_properties or set_property. Between the two, the latter seems to give me a cleaner solution in that I can use both variables coming from Find{BLAS,LAPACK} modules together. When I try to build my library using the above solution, I get the obvious error:

CMake Error at src/CMakeLists.txt:32 (set_property):
  INTERFACE_LIBRARY targets may only have whitelisted properties.  The
  property "LINK_FLAGS" is not allowed.

My question is two folds:

  1. Should I use *_LINKER_FLAGS coming from the modules at all, and,
  2. If yes, how should I integrate them cleanly into my CMake project?

As for the 2. above, I have seen some suggestions/answers for using target_link_libraries, but I am not sure whether that is the option to go for.

Thank you for your time!

Arda Aytekin
  • 1,231
  • 14
  • 24
  • What do you mean by your users? You mean people using your library? – Matthieu Brucher Nov 19 '18 at 12:45
  • Yes, @MatthieuBrucher, I mean the users of the library. In the end, my goal is to have a `cmake`-enabled, social library where you can simply use `add_library(foo foo.c)` and `target_link_libraries(foo PRIVATE polo::polo)` as the user. – Arda Aytekin Nov 19 '18 at 13:00

2 Answers2

2

First of all, I do apologize to the community for cross posting the issue.

Matthieu has tried helping me with two options:

  1. Providing a helper function so that the consumers of the library could call the function to properly handle the LINK_FLAGS, and,
  2. The IMPORTED library option, which he has kept as the final answer (please see the comments there for the motivation).

Unfortunately, neither of these solutions seem to work. The first one is not a clean way of informing the consumer about your dependencies. The second version seems to work with INTERFACE libraries, but any consumer that depends on the INTERFACE library that build an object, such as, e.g., a C-API of the header-only library that builds a SHARED library, has problems building and installing the IMPORTED library.

The solution seems to be to use CMake v3.13 and above, which, as of the posting date, is in the release candidate (rc3) state. Apparently, CMake v3.13 will be introducing INTERFACE_LINK_OPTIONS for such purposes.

EDIT. CMake v3.13 has been released.

Arda Aytekin
  • 1,231
  • 14
  • 24
  • @MatthieuBrucher, CMake `v3.13` has been released and the [`target_link_options`](https://cmake.org/cmake/help/v3.13/command/target_link_options.html) command seems to work. – Arda Aytekin Nov 21 '18 at 15:12
0

The nice thing is that you can provide a helper .cmake for them (called polo-config.cmake).

One option inside the .cmake file is to create an IMPORTED library, which you hold the flags that you want, probably as PUBLIC this time, so that they are propagated to the next user.

Of course, you need to add the library properly, setting up the include paths, the path to the library...

Matthieu Brucher
  • 21,634
  • 7
  • 38
  • 62
  • Thank you for your response. I do appreciate your time, but I still do not understand some things. First, I already provide the consumers of my library with a [config file](https://github.com/pologrp/polo/tree/master/src), which is found by CMake after a call to `find_package(polo)`. This file already lists my dependencies, which I later on use on my CMake project. Why should any consumer of `polo` need to know anything about my dependencies, if I define them properly? I mean, why should I list my libraries as in the example, again, as you have provided? – Arda Aytekin Nov 19 '18 at 15:16
  • By the way, you _might_ have a typo in your function definition --- `target_include_directories` should read `target_link_libraries` for BLAS and LAPACK, I assume, or? – Arda Aytekin Nov 19 '18 at 15:17
  • These are properties of a target that is already built. But they are in CMake language, not in the file itself. So you need a way of propagating these flags from your polo target (that doesn't exist for the user) to the users target, and that what the config file does. – Matthieu Brucher Nov 19 '18 at 15:22
  • And indeed, it was target_link_library. For instance, for pybind11, libsimdpp, they provide functions in their CMakeLists or their .cmake to do proper links with the proper flags. – Matthieu Brucher Nov 19 '18 at 15:23
  • Could you also provide the links in your comment or answer to those libraries' CMake projects, so that I can check? I mean, I _am_ propagating the flags and requirements from my dependencies up to the consumer, if you check my [CMake project](https://github.com/pologrp/polo/blob/master/src/CMakeLists.txt). But I cannot propagate the `LINK_FLAGS` because I am an INTERFACE library. – Arda Aytekin Nov 19 '18 at 15:56
  • 1
    Added also the IMPORTED solution which could fit your purpose better (not sure you should make the used libraries part of your interface, especially if they are shared libs? Except blas/lapack, but would it matter to have them private?) – Matthieu Brucher Nov 19 '18 at 16:03
  • Thank you. I would appreciate if you changed your answer to have the `IMPORTED` version as the solution, which is what I needed. That seems to fix the issue. I do not want to answer my own question as you have come up with this idea, but if you write: `add_library(foo UNKNOWN IMPORTED); target_link_libraries(foo ${BLAS_LIBRARIES} ${LAPACK_LIBRARIES}); set_property(TARGET foo PROPERTY LINK_FLAGS ${BLAS_LINKER_FLAGS} ${LAPACK_LINKER_FLAGS})`, that seems to work. By the way, apparently, you can only use `INTERFACE` properties on `IMPORTED` libraries. *EDIT.* This approach has other problems, tho. – Arda Aytekin Nov 19 '18 at 16:14
  • `IMPORTED` solution fails with "No rule to make target ..." error. I need to check further. – Arda Aytekin Nov 19 '18 at 16:16
  • Done, I removed the "old" solution. – Matthieu Brucher Nov 19 '18 at 16:22
  • Dear Matthieu, I do appreciate your time and thank you once more for your response, but unfortunately, I will be answering my own question from the response of the CMake guys, just to be able to give a proper/correct answer. – Arda Aytekin Nov 19 '18 at 20:09