<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>