<snip>
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
http://trinity.pearsoncomputing.net/wiki/bin/view/Documentation/Releases_3_…
Tim