From kde-bindings Sat Jan 28 16:12:27 2017 From: Stephen Kelly Date: Sat, 28 Jan 2017 16:12:27 +0000 To: kde-bindings Subject: Re: End of 2016 update on PyKF5 bindings Message-Id: <588cc2ec.45aadf0a.33c59.9bb7 () mx ! google ! com> X-MARC-Message: https://marc.info/?l=kde-bindings&m=148561996324565 Hi Shaheed, That's great, thanks for keeping us up to date with your progress! Looking forward to reviewing it. Thanks, Steve. Shaheed Haque wrote: > Hi Steve, > > FWIW, I have rebased [1], debugged, bulk tested, and squashed to the > point where I can focus on adding to the unit tests for the new > functionality [2]. > > Basically, things took longer than expected because when I rebased, I > picked up your fix for the regression around reporting errors from the > clang compiler. That resulted in errors showing that I had some messed > up paths...and when I fixed that, all sort of objects were no longer > "int"s (because they were now being understood by clang :-)). The flip > side of that is of course that the sip_generator can now correctly > handle quite a bit more syntax! I'll be adding some unit tests for > that stuff too. > > You can see the WIP at > https://github.com/ShaheedHaque/extra-cmake-modules/tree/KDE_master_rebase_with_module_separation > (but please don't attempt to merge anything yet). > > More anon. > > Thanks, Shaheed > > [1] To all-but-the-tip of master, that is your > 3e6eb0562e5fd3831d66db4720c67cc950b3536c. > [2] As well as incorporating your feedback about the second > declaration thing and so on. > > On 22 January 2017 at 15:04, Shaheed Haque wrote: >> I see the point. I'll take another look... >> >> On 22 January 2017 at 12:25, Stephen Kelly wrote: >>> >>> Shaheed Haque wrote: >>> >>> > Hi Steve, >>> > >>> > I've tested that this change does not appear to break things. Full >>> > details, including the testing, in >>> > https://git.reviewboard.kde.org/r/129763/. Kindly review. >>> >>> Hi Shaheed, >>> >>> Source files in kcoreaddons are in >>> >>> util/kuser.h >>> >>> for example and then get installed to >>> >>> include/KF5/KCoreAddons/kuser.h >>> >>> for example. >>> >>> Currently the buildsystem adds both >>> >>> include/KF5/KCoreAddons >>> >>> and >>> >>> include/KF5 >>> >>> to the include directories when a consumer users KCoreAddons. That means >>> that a consumer can write either >>> >>> #include >>> >>> (because of the include/KF5/KCoreAddons) >>> >>> or >>> >>> #include >>> >>> (because of the include/KF5) >>> >>> >>> I consider the former legacy and I think we should change it to require >>> the >>> module name for KF6. >>> >>> So, the Sip file needs to know to process >>> >>> util/kuser.h >>> >>> but it needs to generate >>> >>> %TypeHeaderCode >>> #include >>> %End >>> >>> >>> That is why the python interface requires specifying both. >>> >>> It is true that currently the CMake module/function only requires one of >>> those, and it is the cmake function that makes the assumption that using >>> basename is all that is needed. That is only because the CMake API for >>> mappings or pairs like that is inconvenient. I do plan on implementing >>> it though eventually. Other libraries (outside of KF5) do require >>> specifying the directory name like that in includes, so it is a >>> requirement anyway. >>> >>> The assumption that the two are related by exactly a call to basename >>> should >>> not be in the python code/interface. >>> >>> Does that make sense? >>> >>> Thanks, >>> >>> Steve. >> >>