On Mon, 25 May 2015, Alex Merry wrote:
The issue here is that Vc's macros implicitly assume that all compilation
flags (including include paths) are done at the directory level (with
include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is moving
towards doing things at the target level (with target_include_directories(),
target_compile_options() and inheritance from targets passed to
target_link_libraries()).
Yes, exactly. I've tried to find some documenation about this change, but
apart from the rather unhelpful info in e.g.
http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html
I couldn't find anything. I don't even understand why "cmake is moving
towards doing things at the target level".
Now, from the interface of the vc_compile_for_all_implementations macro, I'm
guessing that it is run before you've even created the relevant target, let
alone called target_link_libraries() on it. That makes things a bit tricky.
Basically, as far as I can see, you have two options. One is to use the old
CMake style of calling include_directories() all over the place in your CMake
code (eg: include_directories(${Qt5Core_INCLUDE_DIRS}) when you are going to
be linking against Qt5::Core). I'm not sure if we expose the relevant variable
properly in KF5 for that approach, though.
No, it doesn't. Qt5Core_INCLUDE_DIRS is fine, gives the include
directories, ${KDE4_INCLUDES} isn't -- it evaluates to that generator
expression I quoted.
The other is to create a variant of vc_compile_for_all_implementations that
takes a target rather than a variable to receive object files - this should
ideally use generator expressions to extract include directories etc, but I'm
not sure if generator expressions are powerful enough to deal with the compile
flags properly.
Hm, that doesn't sound too hopeful :-(.
Boudewijn
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
