End of 2016 update on PyKF5 bindings
Stephen Kelly
steveire at gmail.com
Sun Jan 22 12:25:47 UTC 2017
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.
More information about the Kde-bindings
mailing list