[Kde-bindings] Progress report on Py*5 binding generation

[Shaheed Haque]

Hi Steve,

On the other subject of the %Import and the "includes"...

On 22 April 2016 at 08:29, Stephen Kelly <steveire at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20160422/a181a815/attachment.html>