A new attempt on PyKDE5 binding generation

[Shaheed Haque]

Those build dependency and packaging questions are exactly why I keep
making remarks about needing CMake help from folks who are familiar
with current KDE build setups (and, maybe, packaging).

So, to provide some food for thought...

1. The way the tool works is that there is a driver.py program which
you run something like this (simplified):

$ driver.py -I <qt5-include-root>,<kde-include-root>
<root-of-hdrs-to-turn-into-SIP> <dest-dir>

This converts the tree of C++ header files (e.g. /usr/include/KF5)
from argument 1 into a matching tree of SIP files in argument 2, using
the .h files for the -I option to allow the clang parser to be able to
understand the dependencies. Thus, the tool depends on:

- libclang3.9-dev
- python-clang-3.9
- Qt header files
- KDE header files as required
- the header files of the project you are trying to bind

2. You then have to run the SIP compiler to generate the C++ code for
the actual bindings. Thus this step depends on:

- the driver.py (currently in pykde5.git) plus its dependencies as above
- PyQt5 sip files (pyqt5-dev)
- KDE (5) sip files as required, e.g. for KF5
- the SIP files of the project you are trying to bind


In my case, I have all the external dependencies just installed using
apt-get (i.e. header files under /usr/include, SIP files under
/usr/share). A KDE project X developer will need to satisfy those
dependencies somehow. I'm very hazy on how this might be done using,
for example CMake.

Now, for KF5 itself, I propose to just create the initial set of SIP
files in pykde5.git (BTW, I'm fine with the repo being renamed if
deemed appropriate) just to ease the bootstrap process for everybody
else. That said, the reason for my earlier suggestion that some
project Xs might wish to share the repo is that whatever CMake hackery
is required can, I guess, be then centralised to this one repo.

Again, I have no wish to impose this on anybody; all I want to do is
get the PyKDE ecosystem going again, and then it can evolve as needed
(CMake macros/scripts etc, packaging, whatever).

I hope that adds some colour to my earlier hints. Input, and help, welcome.

Thanks, Shaheed


On 3 April 2016 at 23:14, Albert Astals Cid <aacid at kde.org> wrote:
> El diumenge, 3 d’abril de 2016, a les 23:04:48 CEST, Ingo Klöcker va escriure:
>> On Sunday 03 April 2016 20:27:27 Shaheed Haque wrote:
>> > What seems to be causing ripples is my suggestion that I call the
>> > *tool* to create the SIP files something relating to PyKDE5. That made
>> > sense to me since the tools is all about making SIP wrappers for all
>> > of KDE(5) that wants them. Similarly, the current name of the git
>> > repo is pykde5.git and I plan to land the KF5 bindings there.
>> > However, as I suggested, some non-KF5 projects may find it convenient
>> > to host their bindings there too (subject to the what little I
>> > understand about the current CMake setup), and so that name too made
>> > sense to me.
>>
>> What do you think about simply dropping the 5 from the name and instead
>> using the 5 as major version number? So, instead of PyKDE5 it would be
>> PyKDE v5.x.
>
> What is "pykde"?
>
> My very limited understanding is:
>  * set of bindings for python for various libraries released by the KDE
> community.
>  * Those libraries are all Qt5 based
>  * Most of those libraries are part of KF5 but some are not
>
> Since it's not all KF5 we can't call it pykf5.
>
> pyqt5 would be misleading since would seem it's pythong bindings for qt itself
>
> pykdeqt5 is a bit of a mouthful but is not bad either, it's the set of py
> bindings for kde software for qt5
>
> pykde has the "brand recognition" benefit i guess since it's similar to what
> we've been calling it, in that case though i'd prefer we don't use v5.x since
> people would read it as "KDE5" anyway and that's a name we're trying to fight
> off, so if pykde is chosen as a name i'd suggest going with a date based
> versioning like YY.MM
>
> Now I have a different question, given the modularization we've had, does it
> make sense to ship all the pykde bindings in a single repo? Wouldn't it make
> more sense for each library to ship it's binding inside? Would that mean an
> extra dependency for each library? What dependency would that be?
>
> Cheers,
>   Albert
>
>>
>>
>> Regards,
>> Ingo
>
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings