End of 2016 update on PyKF5 bindings
Stephen Kelly
steveire at gmail.com
Mon Jan 2 23:15:50 UTC 2017
Shaheed Haque wrote:
>> Can you extract self-contained commits and propose them for that repo?
>
> What is the review procedure for extra-cmake-modules?
I think there is a reviewboard or something for it.
Posting a link to commits anywhere (eg a branch on github) works for me
anyway too as I find reviewboard unusable for multi-commit branches.
> There is also one
> change which needs to be made in a synchronised fashion between
> extra-cmake-modules and kguiaddons, any suggestions on how to handle that
> are welcome.
Sure, if you post it, we can think about how to do it. I only pushed the
kguiaddons bindings today. I am curious because the patch was very small and
I wonder what could possibly need to be done in concert.
>> You seem to have changed some things in your clone such as using
>>
>> enum.kind == CursorKind.ENUM_CONSTANT_DECL
>>
>> Please extend the unit test in tests/GenerateSipBindings for that and
>> other similar items.
>>
>
> I'm always looking for opportunities to add them but in most cases, the
> fixes modify the text output for a given source in another framework
> component. It is not obvious how to create a simple self-contained test
> case.
Well, what does that change do? You have a comment saying "Skip visibility
attributes and the like.". What does that mean? You encountered an issue
when parsing an enum with a visibility attribute? Then open
tests/GenerateSipBindings/cpplib.h
put an enum with an attribute somewhere, run the tests, watch them fail,
make your fix, run the tests and watch them pass.
Isn't this extremely obvious? What am I missing? Do I misunderstand your
difficulty?
> For example, in the case you noticed, the point of the change only
> becomes apparent when libclang decides to work in a particular way...and I
> have no idea how in general to provoke those cases.
Start with whatever provokes it with whatever header is being processed, and
then simplify. Again, I must be missing something because this is really
obvious, and I'm certain you know how to do this. I must be missing
something.
> My focus beyond the PRs I posted has been to make the system easier to use
> and diagnose, especially for your workflow.
Great, I think I saw some of that stuff with follow-up 'oops - fix
something' commits. If you can present that work in commits which are
already 'fixed' I'd love to see them.
>> > If we can get the PRs merged, and work out item 4 above,
>> > what else might be needed to getting this into production?
>>
>> There are still packaging related issues, but I don't know how to solve
>> them
>> and I would look to others to provide guidance there.
>>
>
> Likewise, assuming the rebase does not fix it, I'm sure I'll need help
> with item 4.
I'm sure I can help with that soon enough.
Thanks,
Steve.
More information about the Kde-bindings
mailing list