<div dir="auto">Hi,<br><br>On 18 May 2017 at 12:51, Andreas Hartmetz <<a href="mailto:ahartmetz@gmail.com">ahartmetz@gmail.com</a>> wrote:<br>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:<br>>> Hi,<br>>><br>>> On 13 May 2017 at 22:04, Sven Brauch <<a href="mailto:mail@svenbrauch.de">mail@svenbrauch.de</a>> wrote:<br>>> > Hi,<br>>> ><br>>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:<br>>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is<br>>> >> not<br>>> >> set. In poking around, I see references to a (new-to-me)<br>>> >> target-based<br>>> ><br>>> >> system, and using that like this:<br>>> > The question is, why do you need to do that?<br>>><br>> The idea with the target based system aka "Modern CMake" is that you say<br>> you want to compile against a library, and that is all you have to do. A<br>> library requires you to add an include path for its own headers, include<br>> paths for headers of one of its dependencies, and link against a bunch<br>> of libraries? All covered by target properties.<br>> If for some reason (e.g. handover to an external tool) you need those<br>> properties, you can still query them. Under enforced names nonetheless,<br>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?<br><br>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.<br><br>>> I'm continuing to experiment with trying to build Python bindings for<br>>> KF5. As part of that, the SIP tooling creates C++ wrapper code which<br>>> must be compiled for each framework, and for that I need to know the<br>>> header file directories. So far, I have simply been hardcoding the<br>>> needed paths on my own system, but I now want to move to using<br>>> standard CMake-based logic instead.<br>>><br>>> (In some sense, this might be seen as similar to the stuff that was<br>>> added to ECM, but I'm trying for a significantly more automated<br>>> approach).<br>>><br>>> Also, I am trying to feel my way towards a Pythonic build system for<br>>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in<br>>> other words I'm interested in using CMake as a stepping stone, not the<br>>> actual build system.<br>>><br>> I would recommend against that unless you really need to have heavy<br>> logic in the build system. A build system's main job is to "solve" a<br>> dependency tree - that is the difference between a build system and a<br>> script that runs the compiler. The dependency tree enables cheap<br>> incremental builds and correct parallel builds. Maybe not that important<br>> for bindings, admittedly.<br>> Your advantage from using Python must be larger than the overhead from<br>> doing your own dependency resolution plus the overhead from the CMake-<br>> Python interfacing plus the build-related facilities that CMake has and<br>> Python doesn't. Or were you considering scons?<br>> PyQt may have chosen Python because qmake sucks, and it needs Python<br>> anyway, so it avoids any extra dependencies. I know from experience that<br>> you really want to avoid extra dependencies in commercial products.<br><br>/me nods vigourosly.<br><br>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:<br><br>- Keep all platform and system independent code in Python<br>- Isolate all platform and system independent logic in CMake<br><br>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.<br><br>(At this point, abstracting CMake away entirely is a minor detail).<br><br>Thanks for the helpful remarks.<br><br>Shaheed<br><br><br><br>>> Thus, I'm after the moral equivalents of:<br>>><br>>>     Foo_INCLUDE_DIRS<br>>>     Foo_COMPILE_FLAGS<br>>><br>>> Thanks, Shaheed<br>>><br>>> > The usual way is to simply call<br>>> ><br>>> >   target_link_libraries(mybinary KF5::KIOCore)<br>>> ><br>>> > and include paths etc. will be set up for your target automatically.<br>>> ><br>>> > Best,<br>>> > Sven<br>><br>> Cheers,<br>> Andreas M9</div>