A new attempt on PyKDE5 binding generation
srhaque at theiet.org
Thu Mar 31 23:04:07 BST 2016
Thanks for all the feedback. Here is what I am thinking:
- The basic tooling might as well keep the PyKDE5 name because the
tool is intended to be used KDE-wide. And the repo name for the tool
is pykde5. This should not be a problem because nobody outside dev
should see this tool. (Plus, I have little enough time as it is, and I
have no desire to waste it on admin changes to git).
- In pykde5.git, the /sip folder presently contains the few
twine2-generated and (presumably) hand-tweaked SIP files that pre-date
the current effort. I propose to create /sip/KF5 tree based on using
the tool to generate the KF5 support. The SIP compiled results from
this would presumably be packaged/branded "PyKF5" as suggested.
- Once I cleanly separate out the rules-engine and make the driver
code a bit more generic, each non-KF5 (KDE) project that wants to
build its own bindings could either add itself to /sip/<project> in
pykde5.git, or consider pykde5.git as an input, and roll-its-own SIP
structure in its repo.
Also, by way of an update, I'm making steady progress. From the set of
files that libkf5.*-dev pulls down on Ubuntu wily, I get 1733 sip
files with less than 200 parsing errors to work through.
On 29 March 2016 at 09:01, Luca Beltrame <lbeltrame at kde.org> wrote:
> Il Sat, 26 Mar 2016 22:30:18 +0000, Shaheed Haque ha scritto:
> Hey Shaheed,
>> about 800 lines of Python code  which can already create 684 .sip
>> files .
> As someone who occasionally worked on PyKDE4 I can say this is nothing
> short of awesome!
>> whatever. If anybody can actually explain, that would be great. In any
>> event, I am hopeful that the structure of the rules engine  will make
> Given that documentation is non-existent, I would say go with your gut
> feeling. We start from a clean slate, let's do these things "properly"
> from the start.
>> Anyway, comments - and help - welcome, especially on #1, #4 and #5 as I
>> intend to focus on #2 and #3 first.
> As others have mentioned, having a rename to PyKF5 (because, like the
> original PyKDE4 focused on kdelibs, I would argue we'd target all the
> Frameworks in the long run) would probably be warranted once things are up
> to speed.
> I wonder if we can get the CI system to test these things once they're
> working, that would also help reduce regressions / breakages.
> Kde-bindings mailing list
> Kde-bindings at kde.org
Kde-bindings mailing list
Kde-bindings at kde.org
More information about the kde-core-devel