[Kde-bindings] A new attempt on PyKDE5 binding generation
Albert Astals Cid
aacid at kde.org
Tue Apr 19 23:47:07 BST 2016
El divendres, 8 d’abril de 2016, a les 1:29:38 CEST, Stephen Kelly va
> 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):
> >> 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'.
Yes, but imho what we do with ECM is already cheating, doing it again would be
double cheating :D
You could bring it up in kde-frameworks for the frameworks masters to read and
> If there's no packaging-related reason to avoid that approach, I wonder if
> we can discuss it.
More information about the kde-core-devel