<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_5_11 Tim