[Kde-bindings] A new attempt on PyKDE5 binding generation
srhaque at theiet.org
Sun Apr 3 13:30:55 BST 2016
On 1 April 2016 at 23:18, Albert Astals Cid <aacid at kde.org> wrote:
> El dijous, 31 de març de 2016, a les 23:04:07 CEST, Shaheed Haque va escriure:
>> 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).
> There is nothing called KDE5, do not call it PyKDE5, doesn't matter that it is
> dev oriented, it's still a wrong name.
OK. I'm not especially excited about this, so at some point I will
have t think of a name I guess ("PythonGeneratorForKDE" is clearly too
long). The good news is that progress continues. The code now:
1. Creates regular SIP files from header files with non-trivial
content. The output here is essentially complete and correct in many
cases, but there are cases where the reconstructed SIP text is not
correct yet (either due to incompleteness of libclang for this
purpose, or my stupidity, or both). Also some files are seemingly
2. To supplement #1, recognises the "Renaming Header" pattern where
the file content is basically one #include, and generates a "Renaming
SIP" to match.
3. Attempts to recognise new-style output using a heuristic (e.g.
uppercase first letter) to generate a "module.sip". With #1 and #2,
and if only as approximation of the module file content, this does
mean that we have SIP files in nominally-usable form (there is a small
hack needed which I am not quite ready to commit).
The next step is moderately tedious: by manual comparison with PyKDE4
sources I want to fix as many of the corner cases in #1 as I can
(tidying up the code where possible). Once I have made a bit of
progress here, I will probably start actually checking in KF5 SIP
files. (I will probably look for some basic CMake assistance from
somebody who understand the KDE5 development setup/build system at
Then, it should be a simple (hah!) step to support, for ALL the hand
annotations in PyKDE4, assuming I can work out what they are for. I am
still hopeful that the rules-based approach will make this tractable
(I will likely have to extend the rules engine to have rules for
classes/structs and maybe typedefs too, but that should be it).
>> - 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
>> > https://mail.kde.org/mailman/listinfo/kde-bindings
More information about the kde-core-devel