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).
- 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
