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

[Stephen Kelly]

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?

> 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.

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
* 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.
* It works with python 2 and 3.
* Nothing is generated 'by hand'
* This is all WIP. I just did it this afternoon.


Thanks,

Steve. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pythontest.py
Type: text/x-python
Size: 918 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20160423/5970e8ad/attachment.py>