Message: previous - next
Month: September 2010

Re: [trinity-devel] Building kdebindings

From: "Timothy Pearson" <kb9vqf@...>
Date: Tue, 14 Sep 2010 16:01:08 -0500
> I don't know whether these decisions are correct. I'll trust you. As long
> as kdebindings works as expected in non-Debian systems _and_ various
> python bindings work in KDE.
> Slackware always uses stock KDE sources from upstream. Thus, if the KDE
> devs were including sip and python support in kdebindings, Patrick would
> not monkey with that. NOt saying who is right or wrong, just sharing
> facts. :)

The Trinity project is upstream now, so it has absolute say in what goes
where and what should be moved/removed. ;-)  That said, the Trinity
project is comprised of multiple individuals (yourself included), and the
developers (myself included) should run major changes past people on this
list before making them.

> SIP was not included with the stock Slackware but available as an extra
> package.
> PyQt3 was not included with the stock Slackware but available as an extra
> package.

At least they are available.  That's good!

> PyKDE is unknown to Slackware. By your description, sounds as though this
> Debian package is the python-specific portion originally packaged with
> kdebindings.

PyKDE is still provided by the Trinity project, just not in kdebindings
any more.  It was moved to <svn root>/libraries/python-kde3

> Sounds as though the first two packages are not strict build
> prerequisites, but recommended build prerequisites and should be
> built/installed by people who want those bindings when building pyKDE. Is
> that correct? Or do users merely install SIP and PyQT after installing KDE
> and those bindings work thereafter with KDE? There has to be some way when
> building kdebindings to provide the foundations hooks so python will work
> with KDE.

They are strict build prerequisites when attempting to build PyKDE.

> How does all of this affect building the core KDE packages? Do I need to
> modify my kdebindings build script?

No, other than you can remove the DO_NOT_COMPILE line completely if you want.

> With that said, I have progressed further with kdebindings.
> I mentioned my scheme to copy on-the-fly in my build script the
> python/sip/sipgen files from 3.5.10. That gets me past the original build
> failure. Of course, your information sounds as though all of that will
> disappear now anyway.
> Sounds good.
> With that said, my builds go for a while before failing. I have patched
> some /usr/include files from kdelibs. All of the patches are one-liners
> adding a specific tqt interface include statement. You can review the
> patches and decide whether they are necessary. Maybe they are, maybe they
> are not with the changes you propose.
> The process is slow because I get to see only one failure when the build
> fails. I add an appropriate include statement and then build again. I
> don't know the QT/TQT interface like you and I have to learn which include
> statement to add. Takes time. Regardless, the three patches I am including
> eliminate the build failures related to those files. Good thing this stuff
> can run in the background. :)
> I just compiled again and received an error I don't know how to fix. Log
> attached.
> I don't now how this is all affected by what just shared, but I suspect we
> are getting closer to building kdebindings. :)

Update to the latest SVN, which removes the python directory.  That will
clear up your build failure. ;-)  You might also want to try compiling
PyKDE from the directory mentioned above; you should have better luck with
the newer sources contained therein.

Also, on a different note, a Web page now exists that details most of the
major changes from stock 3.5.11 to Trinity 3.5.11.  The address is