<div dir="ltr"><div>Hi Steve,<br><br></div>I have yet to look at your changes, but based on our previous discussions, I just pushed <a href="http://commits.kde.org/pykde5/4b010f502d0d444e21bbafa33529fc40af31a735">http://commits.kde.org/pykde5/4b010f502d0d444e21bbafa33529fc40af31a735</a> which I hope makes the SIP compiler work better for your standalone case (i.e. using an "@" selector). More below...<br><div class="gmail_extra"><br><div class="gmail_quote">On 23 April 2016 at 18:04, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Shaheed Haque wrote:<br>
<br>
> As I said, this is a common pattern without an obvious workaround<br>
<br>
</span>It's quite worrying that this is common. I will look into this, because<br>
instinctively I think something can be fixed in the kio headers here.<br>
<span class=""><br>
> Frankly, I doubt this does make sense except where the owner of the code<br>
> cares enough to generate stuff by hand, and I consider this to be a<br>
> non-starter from my point of view.<br>
<br>
</span>I don't know what needs to be generated by hand?<span class=""><br></span></blockquote><div><br></div><div>You are generating the kitemmodelsmod.sip file by hand rather than using the sip_bulk_generator are you not? I assume this is because you are considering doing the same for Grantlee, or that generally, standalone projects might want to do so.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Specifically for KF5, if all the<br>
> framework owners cared enough about the Python bindings, they could have<br>
> written their own, and we would not be having this discussion!<br>
<br>
</span>I'm not certain that's true :).<br>
<span class=""><br>
> Now, the game might change once we have PyQt5 + PyKF5: e.g. binding<br>
> something finite like Krita or whatever might be done by hand, but nobody<br>
> will bother till the core libraries are there. Except that if the tools<br>
> are good enough to handle KF5, there should be few reasons to bother doing<br>
> it by hand.<br>
<br>
</span>Yes, I think we have the same goal there.<br>
<span class=""><br>
> Notice that the hardcoded includes are only needed for the person<br>
> generating/compiling/packaging the bindings in #1. The .SIP files in #2<br>
> can contain the %Extract section, and it will just be ignored by anybody<br>
> %Import'ing it.<br>
<br>
</span>Ah, I didn't realize that. If I understand now, then that's what I was<br>
missing.<br>
<span class=""><br>
> Now, CMake does have a role in #1 in that it could be used to set the<br>
> --includes as you did for the SIP generation. The %Extract includes is<br>
> simply a way to pass this knowledge through SIP to the C++ compilation<br>
> step.<br>
><br>
> Does that sound right?<br>
<br>
</span>I think I understand now, but I don't think that's necessary.<br></blockquote><div><br></div><div>The above commit also adds a README. You might be interested to take a look because it contains more of the rationale behind my overall approach, including some bits that are still TODOs.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've pushed two commits to<br>
<br>
 <a href="https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings" rel="noreferrer" target="_blank">https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings</a><br>
<br>
which contains a fork of your sip_generator and rules_engine. I didn't need<br>
anything else to implement my proof of concept.<br>
<br>
It also contains a cmake macro to generate bindings and install them and<br>
install the sip files. To proove the concept I ported kitemmodels and<br>
kcoreaddons to use the macro:<br>
<br>
 <a href="https://github.com/steveire/kcoreaddons/commit/979c75f3" rel="noreferrer" target="_blank">https://github.com/steveire/kcoreaddons/commit/979c75f3</a><br>
<br>
 <a href="https://github.com/steveire/kitemmodels/commit/d7511fea" rel="noreferrer" target="_blank">https://github.com/steveire/kitemmodels/commit/d7511fea</a><br>
<br>
I can now use the attached python file to use KItemModels.<br>
<br>
Please let me know what you think of this approach.<br>
<br>
Note that<br>
<br>
* IMO It makes sense to version the bindings (and rules) with the source<br></blockquote><div><br></div><div>In general, this certainly makes sense to me too.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* IMO It makes sense to CI test the bindings with the source<br>
* The linking is simple because we are building a real library with cmake,<br>
and so target_link_libraries works (transitively)<br>
* Ditto, we get transitive computation of the include directories to pass to<br>
the generator from CMake.<br></blockquote><div><br></div><div>This is exactly the sort of CMake knowledge I was hoping somebody would bring to the party. And to be clear, I am supportive of whatever make sense from a packager's point of view. Much of the reason for me to want the bulk mode is because it makes it easy for me to test a wide codebase. I hope the changes I have made make all this easier to drive from your point of view.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* It works with python 2 and 3.<br>
* Nothing is generated 'by hand'<br>
* This is all WIP. I just did it this afternoon.<br></blockquote><div><br></div><div>Excellent, thanks. I'll take a look later. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
<br>
Steve.<br>
<br>_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br>
<br></blockquote></div><br></div></div>