End of 2016 update on PyKF5 bindings

[Shaheed Haque]

Just to close the loop on this, in the review I just posted, the postscript
refers to the module generation spport (previosuly known as the bulk
tooling): that can now work with the existing create_sip API.

On 22 January 2017 at 15:04, Shaheed Haque <srhaque at theiet.org> wrote:

> I see the point. I'll take another look...
>
> On 22 January 2017 at 12:25, Stephen Kelly <steveire at 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20170128/e45376fa/attachment.html>