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

Shaheed Haque srhaque at theiet.org
Mon Apr 25 18:56:49 UTC 2016


+1 for the modular CMake-based stuff.

If you can get that going without all the sip_bulk_generator stuff, then
that is great, I'm more focussed on getting through the volume of errors
through automation because of the weaknesses in the Clang automation. If
you stuff works out, then it might well be that this stuff can wither/die.

Sorry for the truncated response, this next few weeks is going to be mad
here.

On 25 April 2016 at 09:04, Stephen Kelly <steveire at gmail.com> wrote:

> 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.
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20160425/e838b121/attachment.html>


More information about the Kde-bindings mailing list