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

[Albert Astals Cid]

El divendres, 8 d’abril de 2016, a les 1:29:38 CEST, Stephen Kelly va 
escriure:
> 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'.

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 
comment.

Cheers,
  Albert

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