Fwd: KF5 CMake usage question

[Aleix Pol]

On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque <srhaque at theiet.org> wrote:
> On 21 May 2017 at 22:27, Aleix Pol <aleixpol at kde.org> wrote:
>> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <srhaque at theiet.org> wrote:
>>> Actually, there is one thing about "target CMake"-based KF5 that I
>>> don't quite understand: is there a way to get to the C++ compile flags
>>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS
>>> but for target Foo? Even if the general answer is "no", I'm interested
>>> in at least the CMake variables/properties/commands needed to get to
>>> "-fPIC" and "-std=gnu++14".
>>>
>>> I'm aware of the target properties
>>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as
>>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to
>>> be set on targets I have tried.
>>>
>>> Perhaps these are only set if somehow the compiler name etc. is specified?
>>>
>>> Thanks, Shaheed
>>>
>>> On 18 May 2017 at 18:04, Shaheed Haque <srhaque at theiet.org> wrote:
>>>> Hi,
>>>>
>>>> On 18 May 2017 at 12:51, Andreas Hartmetz <ahartmetz at gmail.com> wrote:
>>>>> 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?
>>>>
>>>> Ack. The problem from the point of view of an automated tool which starts
>>>> with a component called Foo arises ONLY because the target(s) of Foo are
>>>> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo
>>>> and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS
>>>> etc.
>>>>
>>>>
>>>>>> 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.
>>>>
>>>> /me nods vigourosly.
>>>>
>>>> I'm not (yet) familair with all the intricacies of the Python build system
>>>> (or CMake for that matter!), but I do see that PyQt has to work quite hard
>>>> to keep its build system working as a Python user might expect. Further, the
>>>> system I am seeking to build has to support more than KF5 (or even KDE). So,
>>>> roughly speaking, the split I am going for is:
>>>>
>>>> - Keep all platform and system independent code in Python
>>>> - Isolate all platform and system independent logic in CMake
>>>>
>>>> As I say, I am feeling my way a bit here, but this seems like a
>>>> philosophically justifiable separation. Oh, and to solve the problem of
>>>> finding the targets, I resorted to parsing the CMake files (!!). I can live
>>>> with that hack precisely because by having the split, users of this code who
>>>> are not using it against KF5 will need to replace this CMake part with their
>>>> own anyway.
>>>>
>>>> (At this point, abstracting CMake away entirely is a minor detail).
>>>>
>>>> Thanks for the helpful remarks.
>>>>
>>>> Shaheed
>>>>
>>>>
>>>>
>>>>>> 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 M9
>>
>> You can easily see how it works in extra-cmake-modules code.
>
> I don't think it is quite so simple. First, for "-std=gnu++14",the ECM
> code just hardcodes it (with a comment that hints at difficulties
> extracting this value). Second, it grabs INTERFACE_COMPILE_DEFINITIONS
> and INTERFACE_COMPILE_OPTIONS of which the latter seems to be needed
> in order to get stuff from come KF5 cmake file which set -fexception
> (in some case, for example).
>
> But what sets "-fPIC"? It seems to be inherited in some way from
> Qt5::Core INTERFACE_COMPILE_OPTIONS, but how can I get to that
> programmatically?
>
> Thanks, Shaheed
>
>> Aleix

I don't understand what you're trying to do.
You are not supposed to change the definitions Qt5::Core suggests to
the compiler.

Aleix