Re: End of 2016 update on PyKF5 bindings

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 <[email protected]> wrote:
> I see the point. I'll take another look...
>
> On 22 January 2017 at 12:25, Stephen Kelly <[email protected]> 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.
>
>