[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: End of 2016 update on PyKF5 bindings
From:       Stephen Kelly <steveire () gmail ! com>
Date:       2017-01-28 16:12:27
Message-ID: 588cc2ec.45aadf0a.33c59.9bb7 () mx ! google ! com
[Download RAW message or body]

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 <srhaque@theiet.org> wrote:
> > I see the point. I'll take another look...
> > 
> > On 22 January 2017 at 12:25, Stephen Kelly <steveire@gmail.com> 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 <kuser.h>
> > > 
> > > (because of the include/KF5/KCoreAddons)
> > > 
> > > or
> > > 
> > > #include <KCoreAddons/kuser.h>
> > > 
> > > (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 <KCoreAddons/kuser.h>
> > > %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.
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]