Fwd: KF5 CMake usage question

[Shaheed Haque]

Exactly.

On 23 May 2017 at 20:40, Albert Astals Cid <aacid at kde.org> 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 <srhaque at theiet.org> wrote:
>> > On 21 May 2017 at 22:27, Aleix Pol <aleixpol at kde.org> wrote:
>> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <srhaque at theiet.org>
> wrote:
>> >>> Actually, there is one thing about "target CMake"-based KF5 that I
>> >>> don't quite understand: is there a way to get to the C++ compile flags
>> >>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS
>> >>> but for target Foo? Even if the general answer is "no", I'm interested
>> >>> in at least the CMake variables/properties/commands needed to get to
>> >>> "-fPIC" and "-std=gnu++14".
>> >>>
>> >>> I'm aware of the target properties
>> >>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as
>> >>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to
>> >>> be set on targets I have tried.
>> >>>
>> >>> Perhaps these are only set if somehow the compiler name etc. is
>> >>> specified?
>> >>>
>> >>> Thanks, Shaheed
>> >>>
>> >>> On 18 May 2017 at 18:04, Shaheed Haque <srhaque at theiet.org> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> On 18 May 2017 at 12:51, Andreas Hartmetz <ahartmetz at gmail.com> wrote:
>> >>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> On 13 May 2017 at 22:04, Sven Brauch <mail at svenbrauch.de> wrote:
>> >>>>>> > Hi,
>> >>>>>> >
>> >>>>>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
>> >>>>>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
>> >>>>>> >> not
>> >>>>>> >> set. In poking around, I see references to a (new-to-me)
>> >>>>>> >> target-based
>> >>>>>> >
>> >>>>>> >> system, and using that like this:
>> >>>>>> > The question is, why do you need to do that?
>> >>>>>
>> >>>>> The idea with the target based system aka "Modern CMake" is that you
>> >>>>> say
>> >>>>> you want to compile against a library, and that is all you have to do.
>> >>>>> A
>> >>>>> library requires you to add an include path for its own headers,
>> >>>>> include
>> >>>>> paths for headers of one of its dependencies, and link against a bunch
>> >>>>> of libraries? All covered by target properties.
>> >>>>> If for some reason (e.g. handover to an external tool) you need those
>> >>>>> properties, you can still query them. Under enforced names
>> >>>>> nonetheless,
>> >>>>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?
>> >>>>
>> >>>> Ack. The problem from the point of view of an automated tool which
>> >>>> starts
>> >>>> with a component called Foo arises ONLY because the target(s) of Foo
>> >>>> are
>> >>>> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query
>> >>>> Foo
>> >>>> and somehow find FooFoo and FooBar inorder to look up
>> >>>> FooFoo_INCLUDE_DIRS
>> >>>> etc.
>> >>>>
>> >>>>>> I'm continuing to experiment with trying to build Python bindings for
>> >>>>>> KF5. As part of that, the SIP tooling creates C++ wrapper code which
>> >>>>>> must be compiled for each framework, and for that I need to know the
>> >>>>>> header file directories. So far, I have simply been hardcoding the
>> >>>>>> needed paths on my own system, but I now want to move to using
>> >>>>>> standard CMake-based logic instead.
>> >>>>>>
>> >>>>>> (In some sense, this might be seen as similar to the stuff that was
>> >>>>>> added to ECM, but I'm trying for a significantly more automated
>> >>>>>> approach).
>> >>>>>>
>> >>>>>> Also, I am trying to feel my way towards a Pythonic build system for
>> >>>>>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
>> >>>>>> other words I'm interested in using CMake as a stepping stone, not
>> >>>>>> the
>> >>>>>> actual build system.
>> >>>>>
>> >>>>> I would recommend against that unless you really need to have heavy
>> >>>>> logic in the build system. A build system's main job is to "solve" a
>> >>>>> dependency tree - that is the difference between a build system and a
>> >>>>> script that runs the compiler. The dependency tree enables cheap
>> >>>>> incremental builds and correct parallel builds. Maybe not that
>> >>>>> important
>> >>>>> for bindings, admittedly.
>> >>>>> Your advantage from using Python must be larger than the overhead from
>> >>>>> doing your own dependency resolution plus the overhead from the CMake-
>> >>>>> Python interfacing plus the build-related facilities that CMake has
>> >>>>> and
>> >>>>> Python doesn't. Or were you considering scons?
>> >>>>> PyQt may have chosen Python because qmake sucks, and it needs Python
>> >>>>> anyway, so it avoids any extra dependencies. I know from experience
>> >>>>> that
>> >>>>> you really want to avoid extra dependencies in commercial products.
>> >>>>
>> >>>> /me nods vigourosly.
>> >>>>
>> >>>> I'm not (yet) familair with all the intricacies of the Python build
>> >>>> system
>> >>>> (or CMake for that matter!), but I do see that PyQt has to work quite
>> >>>> hard
>> >>>> to keep its build system working as a Python user might expect.
>> >>>> Further, the system I am seeking to build has to support more than KF5
>> >>>> (or even KDE). So, roughly speaking, the split I am going for is:
>> >>>>
>> >>>> - Keep all platform and system independent code in Python
>> >>>> - Isolate all platform and system independent logic in CMake
>> >>>>
>> >>>> As I say, I am feeling my way a bit here, but this seems like a
>> >>>> philosophically justifiable separation. Oh, and to solve the problem of
>> >>>> finding the targets, I resorted to parsing the CMake files (!!). I can
>> >>>> live
>> >>>> with that hack precisely because by having the split, users of this
>> >>>> code who are not using it against KF5 will need to replace this CMake
>> >>>> part with their own anyway.
>> >>>>
>> >>>> (At this point, abstracting CMake away entirely is a minor detail).
>> >>>>
>> >>>> Thanks for the helpful remarks.
>> >>>>
>> >>>> Shaheed
>> >>>>
>> >>>>>> Thus, I'm after the moral equivalents of:
>> >>>>>>
>> >>>>>> Foo_INCLUDE_DIRS
>> >>>>>> Foo_COMPILE_FLAGS
>> >>>>>>
>> >>>>>> Thanks, Shaheed
>> >>>>>>
>> >>>>>> > The usual way is to simply call
>> >>>>>> >
>> >>>>>> > target_link_libraries(mybinary KF5::KIOCore)
>> >>>>>> >
>> >>>>>> > and include paths etc. will be set up for your target
>> >>>>>> > automatically.
>> >>>>>> >
>> >>>>>> > Best,
>> >>>>>> > Sven
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Andreas M9
>> >>
>> >> You can easily see how it works in extra-cmake-modules code.
>> >
>> > I don't think it is quite so simple. First, for "-std=gnu++14",the ECM
>> > code just hardcodes it (with a comment that hints at difficulties
>> > extracting this value). Second, it grabs INTERFACE_COMPILE_DEFINITIONS
>> > and INTERFACE_COMPILE_OPTIONS of which the latter seems to be needed
>> > in order to get stuff from come KF5 cmake file which set -fexception
>> > (in some case, for example).
>> >
>> > But what sets "-fPIC"? It seems to be inherited in some way from
>> > Qt5::Core INTERFACE_COMPILE_OPTIONS, but how can I get to that
>> > programmatically?
>> >
>> > Thanks, Shaheed
>> >
>> >> Aleix
>>
>> I don't understand what you're trying to do.
>> You are not supposed to change the definitions Qt5::Core suggests to
>> the compiler.
>
> 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
>
>