KF5 CMake usage question

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

KF5 CMake usage question

Shaheed Haque-2
Hi,

I'm a bit confused as to how the current KF5 CMake support works. I
have a small fragment that looks like this:

    find_package(KF5KIO REQUIRED)
    message(STATUS "KF5KIO includes = ${KF5KIO_INCLUDE_DIRS}")

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:

    find_package(ECM REQUIRED NO_MODULE)
    set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
    find_package(KF5 MODULE REQUIRED COMPONENTS KIO)
    get_target_property(hello KF5::KIOCore INTERFACE_INCLUDE_DIRECTORIES)
    message(STATUS "KF5KIO includes = ${hello}")

I now see some useful output. However, note that here I did a
find_package() on KF5 and KIO, but that I had to do a
get_target_property() on KF5::KIOCore. I don't see a programmatic way
to get from (KF5, KIO) to (KF5::KIOCore).

Is there some other way programmatically to get to the include
directories and compile flags for each framework in KF5?

Thanks, Shaheed

P.S. I do see this thread
https://cmake.org/pipermail/cmake-developers/2013-July/019592.html,
which seems to suggest that there should be a variable called
${Foo_TARGETS}, but I've not been able to work out what "Foo" should
be in either case (plus, it is the include directories and compile
flags I am presently interested in, not the libraries).
Reply | Threaded
Open this post in threaded view
|

Fwd: KF5 CMake usage question

Shaheed Haque-2
Hi,

On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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?

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.

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
>

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Andreas Hartmetz-2
On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:

> Hi,
>
> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Shaheed Haque-2
Hi,

On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:

> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>> Hi,
>>
>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Shaheed Haque-2
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 <[hidden email]> wrote:

> Hi,
>
> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>> Hi,
>>>
>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Aleix Pol Gonzalez-2
On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <[hidden email]> 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 <[hidden email]> wrote:
>> Hi,
>>
>> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>>> Hi,
>>>>
>>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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.

Aleix
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Shaheed Haque-2
On 21 May 2017 at 22:27, Aleix Pol <[hidden email]> wrote:

> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <[hidden email]> 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 <[hidden email]> wrote:
>>> Hi,
>>>
>>> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>>>> Hi,
>>>>>
>>>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Aleix Pol Gonzalez-2
In reply to this post by Shaheed Haque-2
On Thu, May 18, 2017 at 7:04 PM, Shaheed Haque <[hidden email]> wrote:

> Hi,
>
> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>> Hi,
>>>
>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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

BTW you don't need to do the parsing, you can run cmake in server mode
and query it: "cmake -E server...".
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Aleix Pol Gonzalez-2
In reply to this post by Shaheed Haque-2
On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque <[hidden email]> wrote:

> On 21 May 2017 at 22:27, Aleix Pol <[hidden email]> wrote:
>> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <[hidden email]> 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 <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Albert Astals Cid-3
El dimarts, 23 de maig de 2017, a les 2:04:54 CEST, Aleix Pol va escriure:
> On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque <[hidden email]> wrote:
> > On 21 May 2017 at 22:27, Aleix Pol <[hidden email]> wrote:
> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <[hidden email]>
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 <[hidden email]> wrote:
> >>>> Hi,
> >>>>
> >>>> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
> >>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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.

As far as i understand he wants to know what Qt5::Core actually expands to so
he can pass it to some other tool.

Cheers,
  Albert

>
> Aleix


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Shaheed Haque-2
In reply to this post by Aleix Pol Gonzalez-2
> I don't understand what you're trying to do.

Me neither :-). Let me take a step back to try to provide some
context. It is my assessment that part of the problem with the
maintenance of bindings has been the lack of automation both in
support of the initial development of the bindings, and then ongoing
maintenance. My overall intention is to try to provide the missing
automation. For our present purposes, we can think of that as having
one part to do with the language support (think C++ templates,
exceptions, ...) being mapped to Python, and a second part to do with
how the code is packaged and delivered.

This second part has some complications for which I don't yet have a
clear solution:

- Steve did some cool stuff in ECM but there are aspects of that which
are not as automated as I think can be achieved and which ties the
overall solution firmly to KDE.

- I observe that PyQt has undergone a good deal of enhancement around
thePython end of the packaging; and the latest incarnation based on
something called a "wheel" seems to be widely appreciated. I want to
try to get to the same point.

- In between C++ and Python is SIP. SIP prsently has its own binding
build tooling to solve part of this problem. But it seems planned for
this to die in the near future.

So, the best transition path between the CMake-based build for KF5 and
the Python end of the "wheel" build and deployment process is not at
all clear to me. Part of the problem is that I don't have much
experience of either and none of the comparable solutions out there
(ECM, PyQt) have quite the same aspirations as I stated above.

So, back to the present point. The Cmake documentation is reasnably
detailed, but light on the overall way things work: specifically, I
have not quite understood how build setting/requirements are
propagated from (say) Qt::Core to KF5::whatever and thenceto the
bindings.

For example, I had hoped that by doing a find package of KF5::Foo, I'd
be able to query from Cmake the needed settingsto compile the
bindings, but that always seems incomplete (e.g. the gnustd++14) I can
make an educated guess as to one possibility: maybe CMake propagates
these things at the point it evaluates the dependencies during a
build, and not before, but the CMake docs I have seen don't actually
seem to explain how the thing works.

So, I'm somewhat in the dark trying to stitch the pieces together.

> You are not supposed to change the definitions Qt5::Core suggests to
> the compiler.

I'm trying to understand how to query the CMake system for what the
settings are supposed to be so that I can - possibly - use some other
build system to achieve it.

> Aleix
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: KF5 CMake usage question

Shaheed Haque-2
In reply to this post by Albert Astals Cid-3
Exactly.

On 23 May 2017 at 20:40, Albert Astals Cid <[hidden email]> wrote:

> El dimarts, 23 de maig de 2017, a les 2:04:54 CEST, Aleix Pol va escriure:
>> On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque <[hidden email]> wrote:
>> > On 21 May 2017 at 22:27, Aleix Pol <[hidden email]> wrote:
>> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <[hidden email]>
> 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 <[hidden email]> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> On 18 May 2017 at 12:51, Andreas Hartmetz <[hidden email]> wrote:
>> >>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> On 13 May 2017 at 22:04, Sven Brauch <[hidden email]> 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.
>
> As far as i understand he wants to know what Qt5::Core actually expands to so
> he can pass it to some other tool.
>
> Cheers,
>   Albert
>
>>
>> Aleix
>
>