Problem using Vc with CMake 3.0 and kf5

[Boudewijn Rempt]

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