Hi Luca, On 5 September 2017 at 23:12, Luca Beltrame <lbeltr...@kde.org> wrote: > Il giorno Tue, 5 Sep 2017 22:12:26 +0100 > Shaheed Haque <srha...@theiet.org> ha scritto: > > Hello Shaheed, > > first of all, thanks for continuing work on the bindings! > >> https://github.com/ShaheedHaque/extra-cmake-modules/tree/shaheed_master/find-modules/module_generation > > Even if WIP, would you mind putting it up for review in Phab? It would > surely be useful for review.
I'm not sure the diff is especially useful as it is spiritually more closely related to the original code in https://cgit.kde.org/pykde5.git/log/?h=srhaque-new-sip-generator, but then got subsetted into the ECM fork before being restored, so that by now, Git has pretty much no clue about anything, but since you asked, I posted it here: https://phabricator.kde.org/D7736 >> The good news is that the approach appears to have lived up to my hope >> in that the amount of rule code for PyKF5 needed appears to be > > How do you handle Framework tiers and their dependencies? It would be > nice to track dependencies if existing: when packaging the current > bindings, sometimes compilation would fail due to a missing sip file > from another Framework. In an ideal world, CMake would catch that. > >> framework with <some ongoing owner other than me for each framework>, >> and consolidate any needed info as Techbase documentation. > > Docs are important. That's why I mentioned them :-). > In fact, I think this approach should be merged > only with enough docs on: > > - How to use it > - How to wrap a Framework > - How to write rules > > Lack of these things is what brought PyKDE4 on the state it was. I believe there is a solid foundation for the SIP approach for both tool maintainers and rule writers (see the various README and HOWTO files) but IMHO, it was lack of automation rather than lack of docs that did for PyKDE4. (SIP does indeed lack detailed docs, but you'll only find that out once you are as deep as I got :-), and there is plenty of coverage for the basics (and good support too). And, FWIW, cppyy is MUCH worse!) >> On balance, as despite the work that has gone into the SIP approach, I >> propose to explore the cppyy option. > > I would want first to have a working implementation in SIP,even just > for familiarity, unless the limitations are so great that the impair > usage. I have enough coverage to be able to say that the scope of what would be needed to get functional bindings is known (to me, at least) to be manageable. (And in any event, we *know* that SIP is enough for PyQt). However, the whole point of my report is to say that after spending thousands of hours of my time on SIP, I've concluded there is a need to check if there are better alternatives from a completeness and sustainability point of view. I would hardly suggest this course of action if I was not VERY concerned! So, no, I don't propose to go further with the SIP code unless cppyy falls even further short. Thanks, Shaheed > -- > Luca Beltrame - KDE Forums team > GPG key ID: A29D259B
