14 Sep
2010
14 Sep
'10
8:53 p.m.
I did some poking around the Trinity source tree, and
it
appears the
reason for the build failures is outdated code. Eons
ago Debian split out
the three components contained in kdebindings into
different source
packages.
The components are:
SIP
PyQt
PyKDE
I agree with this decision for the following reasons:
1. SIP and PyQt are both maintained upstream and function
perfectly with
Trinity as-is; it makes no sense to maintain a
Trinity-specific copy of
these software projects.
2. PyKDE needs to be patched for Trinity, and has already
been moved to
<svnroot>/libraries/python-kde3
3. This decision seems to fit with the general
user-configurability model
of Trinity; some users may want to install the Java/Ruby
bindings, but not
the Python bindings.
With this in mind, I believe the correct course of action
is to remove the
<svnroot>/kdebindings/python folder completely.
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. :)
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.
PyKDE is unknown to Slackware. By your description, sounds as though this Debian package
is the python-specific portion originally packaged with kdebindings.
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.
How does all of this affect building the core KDE packages? Do I need to modify my
kdebindings build script?
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. :)