[Question] Can INTERFACE libraries propogate LINK_FLAGS?
I apologize in advance for using the issue board for a question, but I do not know how to proceed or where to post this question. I have also used StackOverflow already, where a user has tried helping me with a suggestion of using IMPORTED
library, but I could not proceed from there either.
Basically, I have a simple question. Is there a clean, modern CMake way of propagating LINK_FLAGS
of my dependencies up to the consumer, when I am an INTERFACE
library? An exerpt from my CMake project has something like
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}
)
Currently, my above solution fails with
CMake Error at src/CMakeLists.txt:32 (set_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "LINK_FLAGS" is not allowed.
I have also tried adding
add_library(polo_blas_lapack UNKNOWN IMPORTED)
target_link_libraries(polo_blas_lapack
INTERFACE
${BLAS_LIBRARIES}
${LAPACK_LIBRARIES}
)
set_property(
TARGET
polo_blas_lapack
PROPERTY LINK_FLAGS
${BLAS_LINKER_FLAGS}
${LAPACK_LINKER_FLAGS}
)
target_link_libraries(polo
INTERFACE
Threads::Threads
libzmq
cereal
polo_blas_lapack #<- as a workaround
)
which fails when I build the C API that is based on my header-only library:
make[2]: *** No rule to make target 'polo_blas_lapack-NOTFOUND', needed by 'c-api/libpoloapi.so'. Stop.
make[1]: *** [CMakeFiles/Makefile2:109: c-api/CMakeFiles/poloapi.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
The repository for the library is at https://github.com/pologrp/polo.
The whole purpose of this question is to fix this thing without touching the global LINK_FLAGS
properties, as has been done before, which is apparently not the modern way of doing it.