Fwd: KF5 CMake usage question

[Andreas Hartmetz]

On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
> Hi,
> 
> On 13 May 2017 at 22:04, Sven Brauch <mail at svenbrauch.de> wrote:
> > Hi,
> > 
> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
> >> not
> >> set. In poking around, I see references to a (new-to-me)
> >> target-based
> > 
> >> system, and using that like this:
> > The question is, why do you need to do that?
> 
The idea with the target based system aka "Modern CMake" is that you say 
you want to compile against a library, and that is all you have to do. A 
library requires you to add an include path for its own headers, include 
paths for headers of one of its dependencies, and link against a bunch 
of libraries? All covered by target properties.
If for some reason (e.g. handover to an external tool) you need those 
properties, you can still query them. Under enforced names nonetheless, 
unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?

> I'm continuing to experiment with trying to build Python bindings for
> KF5. As part of that, the SIP tooling creates C++ wrapper code which
> must be compiled for each framework, and for that I need to know the
> header file directories. So far, I have simply been hardcoding the
> needed paths on my own system, but I now want to move to using
> standard CMake-based logic instead.
> 
> (In some sense, this might be seen as similar to the stuff that was
> added to ECM, but I'm trying for a significantly more automated
> approach).
> 
> Also, I am trying to feel my way towards a Pythonic build system for
> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
> other words I'm interested in using CMake as a stepping stone, not the
> actual build system.
> 
I would recommend against that unless you really need to have heavy 
logic in the build system. A build system's main job is to "solve" a 
dependency tree - that is the difference between a build system and a 
script that runs the compiler. The dependency tree enables cheap 
incremental builds and correct parallel builds. Maybe not that important 
for bindings, admittedly.
Your advantage from using Python must be larger than the overhead from 
doing your own dependency resolution plus the overhead from the CMake-
Python interfacing plus the build-related facilities that CMake has and 
Python doesn't. Or were you considering scons?
PyQt may have chosen Python because qmake sucks, and it needs Python 
anyway, so it avoids any extra dependencies. I know from experience that 
you really want to avoid extra dependencies in commercial products.

> Thus, I'm after the moral equivalents of:
> 
>     Foo_INCLUDE_DIRS
>     Foo_COMPILE_FLAGS
> 
> Thanks, Shaheed
> 
> > The usual way is to simply call
> > 
> >   target_link_libraries(mybinary KF5::KIOCore)
> > 
> > and include paths etc. will be set up for your target automatically.
> > 
> > Best,
> > Sven

Cheers,
Andreas