super cool! replacing the current PyKF5 repo (and naming it PyKF5 surely is a possibility?
Shaheed Haque <[email protected]> schrieb am So., 3. Apr. 2016 um 14:32 Uhr: > On 1 April 2016 at 23:18, Albert Astals Cid <[email protected]> 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 <[email protected]> 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 > >> > [email protected] > >> > https://mail.kde.org/mailman/listinfo/kde-bindings > > > > > _______________________________________________ > Kde-bindings mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-bindings >
