Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

Exactly.

On 23 May 2017 at 20:40, Albert Astals Cid  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  wrote:
>> > On 21 May 2017 at 22:27, Aleix Pol  wrote:
>> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque 
> 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  wrote:
>>  Hi,
>> 
>>  On 18 May 2017 at 12:51, Andreas Hartmetz  wrote:
>> > On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>> >> Hi,
>> >>
>> >> On 13 May 2017 at 22:04, Sven Brauch  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 

Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

> 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

Re: Fwd: KF5 CMake usage question

[Albert Astals Cid]

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

Re: Fwd: KF5 CMake usage question

[Aleix Pol]

On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque  wrote:
> On 21 May 2017 at 22:27, Aleix Pol  wrote:
>> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque  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  wrote:
 Hi,

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

Re: Fwd: KF5 CMake usage question

[Aleix Pol]

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

Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

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

Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

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

Re: Fwd: KF5 CMake usage question

[Shaheed Haque]

Hi,

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

Re: 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  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