[Kde-bindings] Progress report on Py*5 binding generation

[Shaheed Haque]

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 at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20160423/ca5b7741/attachment.html>