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

[Stephen Kelly]

Shaheed Haque wrote:
>> I don't know what needs to be generated by hand?
>>
> 
> You are generating the kitemmodelsmod.sip file by hand rather than using
> the sip_bulk_generator are you not? 

No, I am not. CMake is generating that file.

>> Please let me know what you think of this approach.
>>
>> Note that
>>
>> * IMO It makes sense to version the bindings (and rules) with the source
> 
> In general, this certainly makes sense to me too.

Great! However, you still seem to be advocating for an external solution, 
and that's what all of your recent changes still focus on.

Do you agree that we should move forward with my modular solution? 
Modularity is a core principle of KF5.

Are you maybe continuing with the external solution for your convenience 
while generating the rules? Or are you advocating for that external solution 
instead? I don't understand, because it seems to be contradictory that the 
modular solution makes sense, but you keep working on the external one.

If that is not the case, then we are still not on the same page, and that 
could be a problem.

If you agree that the modular way is the way forward, then we can work on a 
better API for composing rules. Currently in kcoreaddons I'm duplicating, 
but the limitation might be my python knowledge which is not so advanced.

It also occurs to me that you might not know how to try out my solution. 

You can do this:

 mkdir -p $HOME/dev/bindings
 cd $HOME/dev/bindings
 git clone -b generate-python-bindings git at github.com:steveire/extra-cmake-
modules.git
 git clone git at github.com:steveire/kitemmodels.git
 git clone git at github.com:steveire/kcoreaddons.git
 git clone git at github.com:steveire/kwidgetsaddons.git
 git clone git at github.com:steveire/kjobwidgets.git
 cd extra-cmake-modules
 mkdir build 
 cd build 
 cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/dev/bindings/prefix
 make install
 cd ../..
 cd kitemmodels
 mkdir build 
 cd build 
 cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/dev/bindings/prefix
 make 
 make install
 cd ../..
 cd kcoreaddons
 mkdir build 
 cd build 
 cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/dev/bindings/prefix
 make 
 make install
 cd ../..
 cd kwidgetsaddons
 mkdir build 
 cd build 
 cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/dev/bindings/prefix
 make 
 make install
 cd ../..
 cd kjobwidgets
 mkdir build 
 cd build 
 cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/dev/bindings/prefix
 make 
 make install
 cd ../..
 
 find prefix/share/sip
 find prefix/lib/python*

prefix/lib/python2.7
prefix/lib/python2.7/dist-packages
prefix/lib/python2.7/dist-packages/PyKF5
prefix/lib/python2.7/dist-packages/PyKF5/KCoreAddons.so
prefix/lib/python2.7/dist-packages/PyKF5/__init__.py
prefix/lib/python2.7/dist-packages/PyKF5/KWidgetsAddons.so
prefix/lib/python2.7/dist-packages/PyKF5/KItemModels.so
prefix/lib/python2.7/dist-packages/PyKF5/KJobWidgets.so
prefix/lib/python3.5
prefix/lib/python3.5/dist-packages
prefix/lib/python3.5/dist-packages/PyKF5
prefix/lib/python3.5/dist-packages/PyKF5/KCoreAddons.so
prefix/lib/python3.5/dist-packages/PyKF5/__init__.py
prefix/lib/python3.5/dist-packages/PyKF5/KWidgetsAddons.so
prefix/lib/python3.5/dist-packages/PyKF5/KItemModels.so
prefix/lib/python3.5/dist-packages/PyKF5/KJobWidgets.so


Examine the installed artifacts resulting from each install step, and 
examine the recent commits in each which actually add the bindings 
generation to see what needs to be specified. Everything else is generated 
automatically, not at all 'by hand'. 

You can also run the same pythontest.py for kitemmodels that I posted before 
with both python 2 and 3 after doing that. I didn't make more tests for the 
other new python bindings yet.

Note that I chose kjobwidgets because it depends on kcoreaddons, so you can 
see how easily dependencies (including transitive linking and include 
directories) work out.

This is still WIP, but I think we need to get on the same page about what is 
the way forward, so to make that happen, so I suggest looking through this 
stuff. I'm pretty sure it makes the sip_bulk_generator and sip_compiler 
unnecessary in the end (though maybe you want to keep working on those for 
your own convenience anyway, even if you agree that modular is the way 
forward?).

Shaheed Haque wrote:
> I couldn't easily see what the fork does differently as I couldn't see the
> point from which you started, 

Diff man! man diff!

If you'll forgive me borrowing a joke :)

 http://www.gnu.org/fun/jokes/ed-msg.html

> but I am hoping that the changes I made to
> support your working model will defer the need for it, for a while at
> least.

I looked through the changes you made in the last few days. None of your 
changes affect sip_generator or rules_engine, which are the only parts that 
are needed in the modular solution. 

> Anyway, here are some of the things I have in mind for next steps:
> 
> - (DONE) Fully expand renaming headers. See the README for the rationale,
> but in summary, I don't think we really want to ship bindings for
> kitemmodels, or kitemmodels plus KItemModels, we should be shipping just
> KItemModels.

I think you didn't look at the repo like I posted. This is very simple with 
my modular solution.

> - Automate the injection of manual code using the rules_engine, and scrape
> any relevant manual code from PyKDE4 into rules_PyKF5.

Sounds good.

> - Try to deal with the duplicate forward declarations issue. This looks
> like the next big step in getting the KF5 files through SIP (there are
> still  lot of files which are erroring out, for a lot of reasons...).

I don't know what this one is about.

> Also, I'm going to have limited time for this in the next few weeks, so
> responses may be delayed.

Ok. In the mean-time I will continue creating bindings in a modular way and 
engage others in the discussion about getting it CI tested etc.

Thanks,

Steve.