[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Progress report on Py*5 binding generation
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2016-04-22 21:02:33
Message-ID: CAHAc2jdfuwAFq7L4xWgARZhcAUCCpJq90P+9jKH3v5cNq+ntSg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Steve,
On the other subject of the %Import and the "includes"...
On 22 April 2016 at 08:29, Stephen Kelly <steveire@gmail.com> wrote:
> Hi Shaheed,
>
> Shaheed Haque wrote:
>
> > I think there are many of these. One example is this one:
> >
> > sip/KIOCore/KIOCoremod.sip:%Import KIOCore/kio/kiomod.sip
> > sip/KIOCore/kio/kiomod.sip:%Import KIOCore/KIOCoremod.sip
>
> Where do those sip files come from and why do they depend on each other?
>
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:
/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'])
and now the other way because kio/directorysizejob.h depends on
KIOCore/kfileitem.h:
/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'])
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.
Short of getting people to rewrite their .h code, every other option I
could think of was much harder to do, and less elegant.
>> As the file might be generated by cmake, this might work, but it seems
> >> easier to pass the include directories on the command line. The
> includes
> >> will be different on each platform.
> >>
> >
> > That is correct, but AFAIK, this is just a build time dependency. Once
> the
> > modules are built, nobody will care.
>
> I think that depends on whether bindings are built when building a library
> (which I think makes most sense). In that case, we would want to install
> the
> sip files (somewhere in share/ perhaps) and they should not contain
> hardcoded paths on the filesystem.
>
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!
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.
> > For me, and for now at least, it is important to be able to run on a
> large
> > body of code without generating anything by hand so generating xxxmod.sip
> > files by hand (with or without the %Extract) is not practical.
>
> The files can still be generated, but without the hardcoded includes. What
> am I missing?
>
As an illustration, my mental model is that you might ship the following
packages for your Grantlee bindings;
1. python-grantlee.deb, containing the pygrantlee.so
2. python-grantlee-dev.deb containing the grantleemod.sip file, and all the
individual .sip files.
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.
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.
Does that sound right?
Thanks, Shaheed
> so that you can then just say "from PyKF5 import KItemModels". You'll
> > notice that in support of this, there is a temporary list of hardcoded
> > libraries to link against (a quick hack just to get us going).
>
> I tried this and it didn't work. Can you please try what I am doing as a
> sanity check? I have attached it as a patch.
>
> Thanks,
>
> Steve.
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic