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 <srha...@theiet.org> wrote: > Hi, > > On 18 May 2017 at 12:51, Andreas Hartmetz <ahartm...@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 <m...@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