[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