[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: Shaheed Haque <srhaque () theiet ! org>
Date: 2017-01-28 20:17:09
Message-ID: CAHAc2jeVseM9vvFfrDGkjQC_EHfG6ObPFed0aHVC9bX7jspOQA () mail ! gmail ! com
[Download RAW message or body]
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@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.
>>
>
>
[Attachment #3 (text/html)]
<div dir="ltr">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.<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 22 January 2017 at 15:04, Shaheed \
Haque <span dir="ltr"><<a href="mailto:srhaque@theiet.org" \
target="_blank">srhaque@theiet.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">I see the point. I'll take another \
look...</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div \
class="gmail_quote">On 22 January 2017 at 12:25, Stephen Kelly <span dir="ltr"><<a \
href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><span>Shaheed Haque wrote:<br> <br>
> Hi Steve,<br>
><br>
> I've tested that this change does not appear to break things. Full<br>
> details, including the testing, in<br>
> <a href="https://git.reviewboard.kde.org/r/129763/" rel="noreferrer" \
target="_blank">https://git.reviewboard.kde.or<wbr>g/r/129763/</a>. Kindly \
review.<br> <br>
</span>Hi Shaheed,<br>
<br>
Source files in kcoreaddons are in<br>
<br>
util/kuser.h<br>
<br>
for example and then get installed to<br>
<br>
include/KF5/KCoreAddons/<wbr>kuser.h<br>
<br>
for example.<br>
<br>
Currently the buildsystem adds both<br>
<br>
include/KF5/KCoreAddons<br>
<br>
and<br>
<br>
include/KF5<br>
<br>
to the include directories when a consumer users KCoreAddons. That means<br>
that a consumer can write either<br>
<br>
#include <kuser.h><br>
<br>
(because of the include/KF5/KCoreAddons)<br>
<br>
or<br>
<br>
#include <KCoreAddons/kuser.h><br>
<br>
(because of the include/KF5)<br>
<br>
<br>
I consider the former legacy and I think we should change it to require the<br>
module name for KF6.<br>
<br>
So, the Sip file needs to know to process<br>
<br>
util/kuser.h<br>
<br>
but it needs to generate<br>
<br>
%TypeHeaderCode<br>
#include <KCoreAddons/kuser.h><br>
%End<br>
<br>
<br>
That is why the python interface requires specifying both.<br>
<br>
It is true that currently the CMake module/function only requires one of<br>
those, and it is the cmake function that makes the assumption that using<br>
basename is all that is needed. That is only because the CMake API for<br>
mappings or pairs like that is inconvenient. I do plan on implementing it<br>
though eventually. Other libraries (outside of KF5) do require specifying<br>
the directory name like that in includes, so it is a requirement anyway.<br>
<br>
The assumption that the two are related by exactly a call to basename should<br>
not be in the python code/interface.<br>
<br>
Does that make sense?<br>
<br>
Thanks,<br>
<br>
Steve.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic