[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Progress report on Py*5 binding generation
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2016-04-23 21:08:41
Message-ID: CAHAc2jc7f0riyZYJbm4z3MvnG55MVC5YuYrNTbUobhdZPzcf9A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Steve,
I have yet to look at your changes, but based on our previous discussions,
I just pushed
http://commits.kde.org/pykde5/4b010f502d0d444e21bbafa33529fc40af31a735
which I hope makes the SIP compiler work better for your standalone case
(i.e. using an "@" selector). More below...
On 23 April 2016 at 18:04, Stephen Kelly <steveire@gmail.com> wrote:
> Shaheed Haque wrote:
>
> > As I said, this is a common pattern without an obvious workaround
>
> It's quite worrying that this is common. I will look into this, because
> instinctively I think something can be fixed in the kio headers here.
>
> > Frankly, I doubt this does make sense except where the owner of the code
> > cares enough to generate stuff by hand, and I consider this to be a
> > non-starter from my point of view.
>
> I don't know what needs to be generated by hand?
>
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.
> > Specifically for KF5, if all the
> > framework owners cared enough about the Python bindings, they could have
> > written their own, and we would not be having this discussion!
>
> I'm not certain that's true :).
>
> > Now, the game might change once we have PyQt5 + PyKF5: e.g. binding
> > something finite like Krita or whatever might be done by hand, but nobody
> > will bother till the core libraries are there. Except that if the tools
> > are good enough to handle KF5, there should be few reasons to bother
> doing
> > it by hand.
>
> Yes, I think we have the same goal there.
>
> > Notice that the hardcoded includes are only needed for the person
> > generating/compiling/packaging the bindings in #1. The .SIP files in #2
> > can contain the %Extract section, and it will just be ignored by anybody
> > %Import'ing it.
>
> Ah, I didn't realize that. If I understand now, then that's what I was
> missing.
>
> > Now, CMake does have a role in #1 in that it could be used to set the
> > --includes as you did for the SIP generation. The %Extract includes is
> > simply a way to pass this knowledge through SIP to the C++ compilation
> > step.
> >
> > Does that sound right?
>
> I think I understand now, but I don't think that's necessary.
>
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.
I've pushed two commits to
>
>
> https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings
>
> which contains a fork of your sip_generator and rules_engine. I didn't need
> anything else to implement my proof of concept.
>
> It also contains a cmake macro to generate bindings and install them and
> install the sip files. To proove the concept I ported kitemmodels and
> kcoreaddons to use the macro:
>
> https://github.com/steveire/kcoreaddons/commit/979c75f3
>
> https://github.com/steveire/kitemmodels/commit/d7511fea
>
> I can now use the attached python file to use KItemModels.
>
> Please let me know what you think of this approach.
>
> Note that
>
> * IMO It makes sense to version the bindings (and rules) with the source
>
In general, this certainly makes sense to me too.
> * IMO It makes sense to CI test the bindings with the source
> * The linking is simple because we are building a real library with cmake,
> and so target_link_libraries works (transitively)
> * Ditto, we get transitive computation of the include directories to pass
> to
> the generator from CMake.
>
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.
> * It works with python 2 and 3.
> * Nothing is generated 'by hand'
> * This is all WIP. I just did it this afternoon.
>
Excellent, thanks. I'll take a look later.
Thanks,
>
> Steve.
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic