[Kde-bindings] Progress report on Py*5 binding generation

[Shaheed Haque]

Steve,

I've still not yet had a chance to catch up with all your good works, but I
have just pushed what I consider usable %MethodCode injection [1]. This
includes a naive forward port of the PyKDE4 %MethodCode fragments. The
documentation is updated too. With luck this should provide a good template
for other forms of code injection. %TypeCode is the obvious next target,
and with that in place, I think we'll have all the logic in place to
support most anything PyKDE4 could do but in a sustainable manner.

I'm still in a bit of a crunch time here for the next few weeks, but will
try to make time to look at your fork and maybe %TypeCode.

FWIW, the naive forward port of the PyKDE4 fragments is more or less a
simple import of the original code, and this clearly does not apply in many
cases. What is there is intended more as a demonstration of the techniques
of using either fixed strings, or functions to generate the custom code
needed. In support of this, the sip_bulk_generator has a new option which
can be used to identify rules which have not fired, and likely need to be
rethought.

Thanks, Shaheed

[1] http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066


On 30 April 2016 at 14:42, Stephen Kelly <steveire at gmail.com> wrote:

> Shaheed Haque wrote:
>
> > +1 for the modular CMake-based stuff.
> >
> > If you can get that going without all the sip_bulk_generator stuff, then
> > that is great,
>
> Cool. I have completed some more work on particular frameworks and I
> created
> a cmake build for convenience:
>
>  https://github.com/steveire/frameworks-bindings
>
> Build it all with
>
>  $ mkdir build && cd build
>  $ cmake ..
>  $ make
>
>  $ ls prefix/lib/python3.5/dist-packages/PyKF5/
>   __init__.py  KAuth.so  KCodecs.so  KCompletion.so  KConfigCore.so
>   KConfigGui.so  KConfigWidgets.so  KCoreAddons.so  KDBusAddons.so
>   KGuiAddons.so  KI18n.so  KItemModels.so  KJobWidgets.so
> KWidgetsAddons.so
>
> I still haven't written tests for the generated python modules yet. There
> are still some things to do before getting to that (namely integrating your
> MethodCode work).
>
> > I'm more focussed on getting through the volume of errors
> > through automation because of the weaknesses in the Clang automation.
>
> I also made some changes to how the clang cindex stuff is used in the
> sip_generator.py and in the rules_engine.py. I will soon integrate your
> work
> on %MethodCode injection into the extra-cmake-modules version of the code.
> That should actually make the bindings actually useful, because up to now I
> have been
>
> I encourage you to have a look at what is in the extra-cmake-modules and
> other repos in the mean-time. I have modularized the rules and made it
> possible to re-use the generic Qt5 rules in the modules, but in a bit of a
> hacky way. I think more refactoring should be done on the sip_generator and
> rules to make that kind of thing more of an integral part of the design.
>
> However, I don't want to do major refactoring of the version in the extra-
> cmake-modules repo while you are still changing the version in the pykde5
> repo.
>
> It would be better to not have divergent versions of the generator. Can I
> somehow convince you to continue your work with the modularized approach?
> That would eliminate the work created by having divergent versions, and
> would mean that we are creating modularized bindings, which I think we
> agree
> are desirable? It will result in shippable bindings quite quickly as far as
> I can see.
>
> Thanks,
>
> Steve.
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20160501/529e3a01/attachment.html>