Problem using Vc with CMake 3.0 and kf5

Alex Merry alex.merry at kde.org
Mon May 25 12:18:00 BST 2015


On Monday 25 May 2015 13:03:40 Boudewijn Rempt wrote:
> 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.ht
> ml I couldn't find anything. I don't even understand why "cmake is moving
> towards doing things at the target level".

Well, a combination of convenience (linking against a target does all the 
things necessary, so you don't have to do three separate commands to use a 
library) and correctness (you'll get a configure-time error from a misspelled 
target name, but not a misspelled variable, and you don't end up adding 
include directories or compile flags to targets that don't need them).

> > 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.

Ah, yes. You may get somewhere with
include_directories($<JOIN:${KDE4_INCLUDES}, -I>)

Basically, this should replace all those semicolons in the generated output 
with " -I", which should produce a correct command line. This is untested, 
though.

> > 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 :-(.

Well, it should work for the include directories just fine, which seems to be 
the problem you're actually hitting. Vc does some relatively complex mangling 
of other compile flags, though, which I don't think can be implemented 
directly using generator expressions. But the flags it cares about are 
unlikely to be wrapped up in generator expressions anyway, so it probably 
won't be an issue in practice.

Alex




More information about the calligra-devel mailing list