<div dir="ltr"><div>Hi Steve,<br><br></div>On the other subject of the %Import and the "includes"...<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 22 April 2016 at 08:29, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Shaheed,<br>
<span class=""><br>
Shaheed Haque wrote:<br>
<br>
> I think there are many of these. One example is this one:<br>
><br>
> sip/KIOCore/KIOCoremod.sip:%Import KIOCore/kio/kiomod.sip<br>
> sip/KIOCore/kio/kiomod.sip:%Import KIOCore/KIOCoremod.sip<br>
<br>
</span>Where do those sip files come from and why do they depend on each other?<br></blockquote><div><br></div><div>Here is some data for the case I cited above. First, KIOCoremod.sip has a dependency on kiomod.sip because of cases like this one where KIOCore/kdskfreespaceinfo.h depends on kio/global.h:<br><br></div>/usr/include/KF5/KIOCore/kdiskfreespaceinfo.h ===>>> set(['/usr/include/x86_64-linux-gnu/qt5/QtCore/QSharedDataPointer', '/usr/include/KF5/KIOCore/kio/global.h', '/usr/include/x86_64-linux-gnu/qt5/QtCore/QString', '/usr/include/KF5/KIOCore/kiocore_export.h'])<br><br><div>and now the other way because kio/directorysizejob.h depends on KIOCore/kfileitem.h:<br><br></div><div>/usr/include/KF5/KIOCore/kio/directorysizejob.h ===>>> set(['/usr/include/KF5/KIOCore/kio/job_base.h', '/usr/include/KF5/KIOCore/kfileitem.h', '/usr/include/KF5/KIOCore/kiocore_export.h'])<br><br></div><div>As I said, this is a common pattern without an obvious workaround (I asked, and the SIP folks' response was that supporting recursive %Import was not seen as an enhancement). Frankly, I consider the solution I came up with using %Feature and the "modules.features" file to dynamically break the recursion, within the strictures of what SIP will accept, as a breakthrough.<br><br>Short of getting people to rewrite their .h code, every other option I could think of was much harder to do, and less elegant.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">>> As the file might be generated by cmake, this might work, but it seems<br>
>> easier to pass the include directories on the command line.  The includes<br>
>> will be different on each platform.<br>
>><br>
><br>
> That is correct, but AFAIK, this is just a build time dependency. Once the<br>
> modules are built, nobody will care.<br>
<br>
</span>I think that depends on whether bindings are built when building a library<br>
(which I think makes most sense). In that case, we would want to install the<br>
sip files (somewhere in share/ perhaps) and they should not contain<br>
hardcoded paths on the filesystem.<span class=""><br></span></blockquote><div><br></div><div>Frankly, I doubt this does make sense except where the owner of the code cares enough to generate stuff by hand, and I consider this to be a non-starter from my point of view. Specifically for
 KF5, if all the framework owners cared enough about the Python 
bindings, they could have written their own, and we would not be having this discussion!<br></div><div><div><br></div><div>Now, the game might change once we have PyQt5 + PyKF5: e.g. binding something finite like Krita or whatever might be done by hand, but nobody will bother till the core libraries are there. Except that if the tools are good enough to handle KF5, there should be few reasons to bother doing it by hand.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> For me, and for now at least, it is important to be able to run on a large<br>
> body of code without generating anything by hand so generating xxxmod.sip<br>
> files by hand (with or without the %Extract) is not practical.<br>
<br>
</span>The files can still be generated, but without the hardcoded includes. What<br>
am I missing?<span class=""><br></span></blockquote><div><br></div><div>As an illustration, my mental model is that you might ship the following packages for your Grantlee bindings;<br><br></div><div>1. python-grantlee.deb, containing the pygrantlee.so<br></div><div>2. python-grantlee-dev.deb containing the grantleemod.sip file, and all the individual .sip files.<br></div><div><br></div><div>Notice that the hardcoded includes are only needed for the person generating/compiling/packaging the bindings in #1. The .SIP files in #2 can contain the %Extract section, and it will just be ignored by anybody %Import'ing it.<br><br></div><div>Now, CMake does have a role in #1 in that it could be used to set the --includes as you did for the SIP generation. The %Extract includes is simply a way to pass this knowledge through SIP to the C++ compilation step.<br></div><div><br></div><div>Does that sound right?<br><br></div><div>Thanks, Shaheed<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> so that you can then just say "from PyKF5 import KItemModels". You'll<br>
> notice that in support of this, there is a temporary list of hardcoded<br>
> libraries to link against (a quick hack just to get us going).<br>
<br>
</span>I tried this and it didn't work. Can you please try what I am doing as a<br>
sanity check? I have attached it as a patch.<br>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br>
<br></blockquote></div><br></div></div></div></div>