13 Sep
13 Sep
5:17 p.m.
New subject: [trinity-devel] Building kdebindings
FTBFS. Build log and build script attached.
Darrell
Try adding this to your configure string:
DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'
Treat it as a configure flag; e.g. if your configure command was:
./configure --prefix=/opt/trinity
the new command would be:
./configure --prefix=/opt/trinity DO_NOT_COMPILE='dcopperl kalyptus
qtsharp xparts python'
From what I can tell gcc might be trying to compile something it
shouldn't. The above line was required under Debian, but does not remove
any functionality from the resulting build as far as I can tell.
Tim
8:32 p.m.
New subject: [trinity-devel] Building kdebindings
Try adding this to your configure string:
DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'
Treat it as a configure flag; e.g. if your configure
command was:
./configure --prefix=/opt/trinity
the new command would be:
./configure --prefix=/opt/trinity DO_NOT_COMPILE='dcopperl
kalyptus
qtsharp xparts python'
From what I can tell gcc might be trying to compile
something it
shouldn't. The above line was required under Debian,
but does not remove
any functionality from the resulting build as far as I can
tell.
Okay. The package finally built. The package size is about 8 MB, which is about 6 MB
smaller than the stock 3.5.10 package. I have not yet compared the package contents.
Possibly unrelated whatsoever, but when I was tinkering with Lenny earlier this year I
never got rpc.rwalld to work with the KDE write daemon to provide KDE popups from rwalld
messages. I wonder whether no functionality is lost.
9:45 p.m.
New subject: [trinity-devel] Building kdebindings
Try adding
this to your configure string:
DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'
Treat it as a configure flag; e.g. if your configure
command was:
./configure --prefix=/opt/trinity
the new command would be:
./configure --prefix=/opt/trinity DO_NOT_COMPILE='dcopperl
kalyptus
qtsharp xparts python'
From what I can tell gcc might be trying to compile
something it
shouldn't. The above line was required under Debian,
but does not remove
any functionality from the resulting build as far as I can
tell.
Okay. The package finally built. The package size is about 8 MB, which is
about 6 MB smaller than the stock 3.5.10 package. I have not yet compared
the package contents.
Possibly unrelated whatsoever, but when I was tinkering with Lenny earlier
this year I never got rpc.rwalld to work with the KDE write daemon to
provide KDE popups from rwalld messages. I wonder whether no functionality
is lost.
10:44 p.m.
New subject: [trinity-devel] Building kdebindings
That new info makes me wonder as well. I guess
we'll
find out! Either
way, I don't think I'll be able to reactivate/fix such a
large chunk of
code before the 3.5.12 release; it will probably have to
wait 6 months or
so for 3.5.13.
As I mentioned the problem could be unrelated.
I use rwalld to keep my htpc communicating with my office system, which is the computer I
spend the most time. I get nice little popups at my office machine. I'm always
tinkering and experimenting with my htpc and I need the communications mechanism to know
what the htpc is doing so I can monitor.
I might very well have migrated to Debian this past spring if I had solved that one little
problem. I could still migrate to Debian if I ever solve that problem.
I played with the configure parameters you provided.
First pass, all parameters:
DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'
Compiled.
Second pass:
DO_NOT_COMPILE='kalyptus qtsharp xparts python'
Compiled.
Third pass:
DO_NOT_COMPILE='python'
Compiled.
Perhaps then we're no longer talking about large chunks. Just one element. At least
now we know the problem area.
Package size remains at about 8 MB. Obvious then is the python bindings comprise a
significant portion of the package.
Of course, python bindings are important to many people.
Amarok scripts are written in python, but I don't know whether those scripts depend
upon kdebindings or are just run external to Amarok.
14 Sep
14 Sep
1:07 a.m.
New subject: [trinity-devel] Building kdebindings
I might have narrowed the focus for kdebindings. :)
In my build script, after I run libtools to auto-generate the makefiles, and before I run
configure, I copied the original stock 3.5.10 python/sip/sipgen directory files over the
svn version. (Remember that during my builds my svn version of the package sources are in
tmpfs.)
By golly the build did not fail at the same point.
Comparing the 3.5.10 and svn python/sip/sipgen directories reveals the svn version
referencing TQT interface objects. I'm guessing the previous build failures have
something to do with that.
My on-the-fly replacement of the files removed the TQT interface references.
Based upon the many past fixes I've seen, I suspect the solution might be some
<include tqt*whatever.h. statements.
The previous failures always took place in lexer.l. I do not notice any <include
tqt*whatever.h> statements. That might be the only file that needs appropriate include
statements, but also might mean the compile only stopped at that point and other files in
that same directory need similar include statements.
The build eventually failed:
==========================================
make[4]: Entering directory `/dev/shm/kdebindings/python/pykde/kdeui'
g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -I. -I../extra/kde353 -I/usr/include
-I/dev/shm/kdebindings/python/sip/siplib -I/usr/include/python2.5
-I/usr/lib/qt/mkspecs/default -I/usr/lib/qt//include -I/usr/X11R6/include -o
sipkdeuiKInputDialog.o sipkdeuiKInputDialog.cpp
In file included from sip/kdeui/kinputdialog.sip:32,
from sipkdeuiKInputDialog.cpp:25:
/usr/include/kinputdialog.h:58: error: 'QValidator' has not been declared
/usr/include/kinputdialog.h:119: error: 'QValidator' has not been declared
/usr/include/kinputdialog.h:132: error: 'QValidator' has not been declared
sipkdeuiKInputDialog.cpp: In function 'PyObject* meth_KInputDialog_getText(PyObject*,
PyObject*)':
sipkdeuiKInputDialog.cpp:116: error: no matching function for call to
'KInputDialog::getText(const QString&, const QString&, const QString&,
bool*, QWidget*&, const char*&, QValidator*&, const QString&)'
/usr/include/kinputdialog.h:120: note: candidates are: static QString
KInputDialog::getText(const QString&, const QString&, const QString&, bool*,
QWidget*, const char*, int*, const QString&)
sipkdeuiKInputDialog.cpp: In function 'PyObject* meth_KInputDialog_text(PyObject*,
PyObject*)':
sipkdeuiKInputDialog.cpp:163: error: no matching function for call to
'KInputDialog::text(const QString&, const QString&, const QString&, bool*,
QWidget*&, const char*&, QValidator*&, const QString&, const
QString&)'
/usr/include/kinputdialog.h:134: note: candidates are: static QString
KInputDialog::text(const QString&, const QString&, const QString&, bool*,
QWidget*, const char*, int*, const QString&, const QString&)
make[4]: *** [sipkdeuiKInputDialog.o] Error 1
make[4]: Leaving directory `/dev/shm/kdebindings/python/pykde/kdeui'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/dev/shm/kdebindings/python/pykde'
make[2]: *** [build_pyqt_pykde] Error 2
make[2]: Leaving directory `/dev/shm/kdebindings/python'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/dev/shm/kdebindings'
make: *** [all] Error 2
==========================================
I believe those errors are related to my copying the original sipgen files. The build ran
for about 26 minutes before failing, unlike the previous 3 and half minutes. Thus, I'm
encouraged we might now be on the right track of solving this problem.
I hope that helps!
7:32 p.m.
New subject: [trinity-devel] Building kdebindings
I might have narrowed the focus for kdebindings. :)
In my build script, after I run libtools to auto-generate the makefiles,
and before I run configure, I copied the original stock 3.5.10
python/sip/sipgen directory files over the svn version. (Remember that
during my builds my svn version of the package sources are in tmpfs.)
By golly the build did not fail at the same point.
Comparing the 3.5.10 and svn python/sip/sipgen directories reveals the svn
version referencing TQT interface objects. I'm guessing the previous build
failures have something to do with that.
My on-the-fly replacement of the files removed the TQT interface
references.
Based upon the many past fixes I've seen, I suspect the solution might be
some <include tqt*whatever.h. statements.
The previous failures always took place in lexer.l. I do not notice any
<include tqt*whatever.h> statements. That might be the only file that
needs appropriate include statements, but also might mean the compile only
stopped at that point and other files in that same directory need similar
include statements.
The build eventually failed:
==========================================
make[4]: Entering directory `/dev/shm/kdebindings/python/pykde/kdeui'
g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -Wall -W -D_REENTRANT
-DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../extra/kde353 -I/usr/include
-I/dev/shm/kdebindings/python/sip/siplib -I/usr/include/python2.5
-I/usr/lib/qt/mkspecs/default -I/usr/lib/qt//include -I/usr/X11R6/include
-o sipkdeuiKInputDialog.o sipkdeuiKInputDialog.cpp
In file included from sip/kdeui/kinputdialog.sip:32,
from sipkdeuiKInputDialog.cpp:25:
/usr/include/kinputdialog.h:58: error: 'QValidator' has not been declared
/usr/include/kinputdialog.h:119: error: 'QValidator' has not been declared
/usr/include/kinputdialog.h:132: error: 'QValidator' has not been declared
sipkdeuiKInputDialog.cpp: In function 'PyObject*
meth_KInputDialog_getText(PyObject*, PyObject*)':
sipkdeuiKInputDialog.cpp:116: error: no matching function for call to
'KInputDialog::getText(const QString&, const QString&, const QString&,
bool*, QWidget*&, const char*&, QValidator*&, const QString&)'
/usr/include/kinputdialog.h:120: note: candidates are: static QString
KInputDialog::getText(const QString&, const QString&, const QString&,
bool*, QWidget*, const char*, int*, const QString&)
sipkdeuiKInputDialog.cpp: In function 'PyObject*
meth_KInputDialog_text(PyObject*, PyObject*)':
sipkdeuiKInputDialog.cpp:163: error: no matching function for call to
'KInputDialog::text(const QString&, const QString&, const QString&,
bool*,
QWidget*&, const char*&, QValidator*&, const QString&, const
QString&)'
/usr/include/kinputdialog.h:134: note: candidates are: static QString
KInputDialog::text(const QString&, const QString&, const QString&, bool*,
QWidget*, const char*, int*, const QString&, const QString&)
make[4]: *** [sipkdeuiKInputDialog.o] Error 1
make[4]: Leaving directory `/dev/shm/kdebindings/python/pykde/kdeui'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/dev/shm/kdebindings/python/pykde'
make[2]: *** [build_pyqt_pykde] Error 2
make[2]: Leaving directory `/dev/shm/kdebindings/python'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/dev/shm/kdebindings'
make: *** [all] Error 2
==========================================
I believe those errors are related to my copying the original sipgen
files. The build ran for about 26 minutes before failing, unlike the
previous 3 and half minutes. Thus, I'm encouraged we might now be on the
right track of solving this problem.
I hope that helps!
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.
Tim
5245
days inactive
5249
days old
6 comments
2 participants
participants (2)
-
Darrell Anderson -
Timothy Pearson