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

[Shaheed Haque]

I forgot to add...

The present code includes a change to the way the sip["decl"] entry is used
in function rules. Instead of being the ", ".join() of all the function
arguments on input to the rule's functor, this is now just the array of
function arguments. The functor should just modify the array as needed
instead of returning a string. The same applies to
sip["template_parameters"].

I'm hoping this is not overly disruptive for you!

Thanks, Shaheed


On 1 May 2016 at 11:18, Shaheed Haque <srhaque at theiet.org> wrote:

> 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/2dec72f4/attachment-0001.html>