Exactly.
On 23 May 2017 at 20:40, Albert Astals Cid <aa...@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 <srha...@theiet.org> wrote: >> > On 21 May 2017 at 22:27, Aleix Pol <aleix...@kde.org> wrote: >> >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <srha...@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 <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 >> >> >> >> 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 > >
