End of 2016 update on PyKF5 bindings

[Stephen Kelly]

Shaheed Haque wrote:

>> It is my intention to add that and other databases which are currently
>> 'missing', when
>>
>>  * We have some tests for them in the ECM repo
>>  * We want to add bindings to a framework (in a KDE repo) which requires
>> them
> 
> To your first point, the bulk generator/compiler tools *are* test
> tools as far as KF5 is concerned...they happen not to fit the
> repository-aligned model because for my present purposes, I want to be
> able to easily run them en-masse across /usr/include/KF5.

Yes. I consider having unit tests in the ECM repo (and versioned with the 
scripts) essential.

Regarding my second point above, my next target is to add bindings to the 
KDE ki18n repo. That will require adding the ModuleCodeDb and MethodCodeDb 
to ECM. I'm working on autotest extensions for those.

>>  I'm looking through the branches/commits in your github repo to see what
>>  can
>> be applied easily now. It looks like your
>> KDE_fix_parameter_initialisation fixes kguiaddons for you, however, I can
>> build kguiaddons with no problem without that patch. Can you
>> double-check, and add a unit test in ECM if you can confirm this needs to
>> be done?
> 
> Please don't take stuff from commits/branches I've indicated are not
> ready as I am actively rewriting them! 

I believe what I referred to above are part of your review requests.

> I'll look and see if I can create a test case but as per my response
> on the review, this is definitely a problem for me. I'll report back
> via the review.

Great, thanks!

>> I also saw that you have a change to how the rules engine is populated
>> (add_rules method). Could you make a commit for that based on master, and
>> port the ECM test to use it?
> 
> For me, to avoid creating a bunch of rebasing effort

I think the best way to avoid rebasing effort is to get the missing pieces 
into ECM quickly (with tests), and preferably used by other frameworks 
repos. Then the only external piece is the bulk generator, right?

> As above, I've put it in a subdirectory to keep it out of the way, and
> if needed, this can stay on a branch or something. But I do want to
> get it into the same repo as the sip_compiler.py if at all possible.
> 
> How does that sound?

If it's in a different branch, how is that different from being in a 
different clone?

Thanks,

Steve.