<div dir="ltr"><div><div><div>I forgot to add...<br><br></div>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"].<br><br></div>I'm hoping this is not overly disruptive for you!<br><br></div>Thanks, Shaheed<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 May 2016 at 11:18, Shaheed Haque <span dir="ltr"><<a href="mailto:srhaque@theiet.org" target="_blank">srhaque@theiet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Steve,<br><br></div>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.<br><br></div>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.<br><div><br></div><div>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.<br></div><div><br></div><div>Thanks, Shaheed<br></div><div><br>[1] <a href="http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066" target="_blank">http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066</a><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 30 April 2016 at 14:42, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Shaheed Haque wrote:<br>
<br>
> +1 for the modular CMake-based stuff.<br>
><br>
> If you can get that going without all the sip_bulk_generator stuff, then<br>
> that is great,<br>
<br>
</span>Cool. I have completed some more work on particular frameworks and I created<br>
a cmake build for convenience:<br>
<br>
 <a href="https://github.com/steveire/frameworks-bindings" rel="noreferrer" target="_blank">https://github.com/steveire/frameworks-bindings</a><br>
<br>
Build it all with<br>
<br>
 $ mkdir build && cd build<br>
 $ cmake ..<br>
 $ make<br>
<br>
 $ ls prefix/lib/python3.5/dist-packages/PyKF5/<br>
  __init__.py  KAuth.so  KCodecs.so  KCompletion.so  KConfigCore.so<br>
  KConfigGui.so  KConfigWidgets.so  KCoreAddons.so  KDBusAddons.so<br>
  KGuiAddons.so  KI18n.so  KItemModels.so  KJobWidgets.so  KWidgetsAddons.so<br>
<br>
I still haven't written tests for the generated python modules yet. There<br>
are still some things to do before getting to that (namely integrating your<br>
MethodCode work).<br>
<span><br>
> I'm more focussed on getting through the volume of errors<br>
> through automation because of the weaknesses in the Clang automation.<br>
<br>
</span>I also made some changes to how the clang cindex stuff is used in the<br>
sip_generator.py and in the rules_engine.py. I will soon integrate your work<br>
on %MethodCode injection into the extra-cmake-modules version of the code.<br>
That should actually make the bindings actually useful, because up to now I<br>
have been<br>
<br>
I encourage you to have a look at what is in the extra-cmake-modules and<br>
other repos in the mean-time. I have modularized the rules and made it<br>
possible to re-use the generic Qt5 rules in the modules, but in a bit of a<br>
hacky way. I think more refactoring should be done on the sip_generator and<br>
rules to make that kind of thing more of an integral part of the design.<br>
<br>
However, I don't want to do major refactoring of the version in the extra-<br>
cmake-modules repo while you are still changing the version in the pykde5<br>
repo.<br>
<br>
It would be better to not have divergent versions of the generator. Can I<br>
somehow convince you to continue your work with the modularized approach?<br>
That would eliminate the work created by having divergent versions, and<br>
would mean that we are creating modularized bindings, which I think we agree<br>
are desirable? It will result in shippable bindings quite quickly as far as<br>
I can see.<br>
<div><div><br>
Thanks,<br>
<br>
Steve.<br>
_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org" target="_blank">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>