Re: End of 2016 update on PyKF5 bindings

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.