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

[Shaheed Haque]

Hi Steve,

I couldn't easily see what the fork does differently as I couldn't see the
point from which you started, but I am hoping that the changes I made to
support your working model will defer the need for it, for a while at
least. Anyway, here are some of the things I have in mind for next steps:

- (DONE) Fully expand renaming headers. See the README for the rationale,
but in summary, I don't think we really want to ship bindings for
kitemmodels, or kitemmodels plus KItemModels, we should be shipping just
KItemModels.

- Automate the injection of manual code using the rules_engine, and scrape
any relevant manual code from PyKDE4 into rules_PyKF5.

- Try to deal with the duplicate forward declarations issue. This looks
like the next big step in getting the KF5 files through SIP (there are
still  lot of files which are erroring out, for a lot of reasons...).

Also, I'm going to have limited time for this in the next few weeks, so
responses may be delayed.

Thanks, Shaheed


On 23 April 2016 at 22:08, Shaheed Haque <srhaque at theiet.org> wrote:

> 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/20160424/fc7fb44d/attachment.html>