A new attempt on PyKDE5 binding generation

[Philipp A.]

super cool!

replacing the current PyKF5 repo (and naming it PyKF5 surely is a
possibility?

Shaheed Haque <srhaque at theiet.org> schrieb am So., 3. Apr. 2016 um
14:32 Uhr:

> On 1 April 2016 at 23:18, Albert Astals Cid <aacid at kde.org> wrote:
> > El dijous, 31 de març de 2016, a les 23:04:07 CEST, Shaheed Haque va
> escriure:
> >> Thanks for all the feedback. Here is what I am thinking:
> >>
> >> - The basic tooling might as well keep the PyKDE5 name because the
> >> tool is intended to be used KDE-wide. And the repo name for the tool
> >> is pykde5. This should not be a problem because nobody outside dev
> >> should see this tool. (Plus, I have little enough time as it is, and I
> >> have no desire to waste it on admin changes to git).
> >
> > There is nothing called KDE5, do not call it PyKDE5, doesn't matter that
> it is
> > dev oriented, it's still a wrong name.
>
> OK. I'm not especially excited about this, so at some point I will
> have t think of a name I guess ("PythonGeneratorForKDE" is clearly too
> long). The good news is that progress continues. The code now:
>
>
> 1. Creates regular SIP files from header files with non-trivial
> content. The output here is essentially complete and correct in many
> cases, but there are cases where the reconstructed SIP text is not
> correct yet (either due to incompleteness of libclang for this
> purpose, or my stupidity, or both). Also some files are seemingly
> ignored.
>
> 2. To supplement #1, recognises the "Renaming Header" pattern where
> the file content is basically one #include, and generates a "Renaming
> SIP" to match.
>
> 3. Attempts to recognise new-style output using a heuristic (e.g.
> uppercase first letter) to generate a "module.sip". With #1 and #2,
> and if only as approximation of the module file content, this does
> mean that we have SIP files in nominally-usable form (there is a small
> hack needed which I am not quite ready to commit).
>
>
> The next step is moderately tedious: by manual comparison with PyKDE4
> sources I want to fix as many of the corner cases in #1 as I can
> (tidying up the code where possible). Once I have made a bit of
> progress here, I will probably start actually checking in KF5 SIP
> files. (I will probably look for some basic CMake assistance from
> somebody who understand the KDE5 development setup/build system at
> this time).
>
> Then, it should be a simple (hah!) step to support, for ALL the hand
> annotations in PyKDE4, assuming I can work out what they are for. I am
> still hopeful that the rules-based approach will make this tractable
> (I will likely have to extend the rules engine to have rules for
> classes/structs and maybe typedefs too, but that should be it).
>
> Thanks, Shaheed
>
>
> > Cheers,
> >   Albert
> >
> >>
> >> - In pykde5.git, the /sip folder presently contains the few
> >> twine2-generated and (presumably) hand-tweaked SIP files that pre-date
> >> the current effort. I propose to create /sip/KF5 tree based on using
> >> the tool to generate the KF5 support. The SIP compiled results from
> >> this would presumably be packaged/branded "PyKF5" as suggested.
> >>
> >> - Once I cleanly separate out the rules-engine and make the driver
> >> code a bit more generic, each non-KF5 (KDE) project that wants to
> >> build its own bindings could either add itself to /sip/<project> in
> >> pykde5.git, or consider pykde5.git as an input, and roll-its-own SIP
> >> structure in its repo.
> >>
> >> Also, by way of an update, I'm making steady progress. From the set of
> >> files that libkf5.*-dev pulls down on Ubuntu wily, I get 1733 sip
> >> files with less than 200 parsing errors to work through.
> >>
> >> On 29 March 2016 at 09:01, Luca Beltrame <lbeltrame at kde.org> wrote:
> >> > Il Sat, 26 Mar 2016 22:30:18 +0000, Shaheed Haque ha scritto:
> >> >
> >> > Hey Shaheed,
> >> >
> >> >> about 800 lines of Python code [2] which can already create 684 .sip
> >> >> files [3].
> >> >
> >> > As someone who occasionally worked on PyKDE4 I can say this is nothing
> >> > short of awesome!
> >> >
> >> >> whatever. If anybody can actually explain, that would be great. In
> any
> >> >> event, I am hopeful that the structure of the rules engine [4] will
> make
> >> >
> >> > Given that documentation is non-existent, I would say go with your gut
> >> > feeling. We start from a clean slate, let's do these things "properly"
> >> > from the start.
> >> >
> >> >> Anyway, comments - and help - welcome, especially on #1, #4 and #5
> as I
> >> >> intend to focus on #2 and #3 first.
> >> >
> >> > As others have mentioned, having a rename to PyKF5 (because, like the
> >> > original PyKDE4 focused on kdelibs, I would argue we'd target all the
> >> > Frameworks in the long run) would probably be warranted once things
> are up
> >> > to speed.
> >> >
> >> > I wonder if we can get the CI system to test these things once they're
> >> > working, that would also help reduce regressions / breakages.
> >> >
> >> > _______________________________________________
> >> > Kde-bindings mailing list
> >> > Kde-bindings at kde.org
> >> > https://mail.kde.org/mailman/listinfo/kde-bindings
> >
> >
> _______________________________________________
> 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-core-devel/attachments/20160403/b08f67cf/attachment.htm>
-------------- next part --------------
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings