[Kde-bindings] A new attempt on PyKDE5 binding generation

Stephen Kelly steveire at gmail.com
Fri Apr 8 00:29:38 BST 2016


Albert Astals Cid wrote:

> El divendres, 8 d’abril de 2016, a les 0:29:57 CEST, Stephen Kelly va
> escriure:
>> Albert Astals Cid wrote:
>> > So my suggestion would be renaming pykde5.git to pykf5.git, and that
>> > means *only* KDE Frameworks 5 bindings would go in there, any other
>> > repo that wants to provide python bindings (say okular, marble or
>> > krita) should do somewhere else, ideally their own repo so the binding
>> > and the original code are close together and it's easier to keep in
>> > sync when api changes.
>> 
>> FYI, this issue came up recently in the context of bindings to another
>> language (QML):
>> 
>>  
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/30734/focus=30770
>> 
>> I'm not very familiar with python bindings generally. Would it be
>> practical to put the bindings in the same repo as the library they relate
>> to?
> 
> See the answer he made to one of my previous emails, in short no.

Ah, yes. I see that this exact issue was discussed already. I wasn't reading 
closely enough when catching up on this thread, so sorry for that.

However, the answer doesn't seem to shorten to 'no' to me. 

A CMake macro can be put in extra-cmake-modules, and the tools for binding 
generation can be put 'somewhere' which doesn't constitute a 'part of the 
tiers' in the same way that ECM is not 'part of the tiers' for the purpose 
of deciding 'what is tier 1'.

If there's no packaging-related reason to avoid that approach, I wonder if 
we can discuss it.

Thanks,

Steve.






More information about the kde-core-devel mailing list