Re: End of 2016 update on PyKF5 bindings

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.