19 Jul
2011
19 Jul
'11
11:20 p.m.
On 20 Jul 2011, Timothy Pearson outgrape:
Ah. Well, it's not working for me then :)
Oh, I'm certain something is different, hence the need for the patches I
sent earlier. Among other things, my Qt setup is a bit unusual: Qt3 is
installed in /usr, with the include path renamed to /usr/include/Qt to
avoid a clash with Qt4: but all of KDE3, and the bin/ directory from
Qt3, is installed in a tree rooted at /usr/kde3/. TQt et al are also
installed in the /usr/kde3/-rooted tree. (This setup allows programs
that use Qt3 to run with no unusual library or include search paths:
they only need an unusual PATH and a couple of -L and -I options at
build time, when uic et al are run.)
In pre-Trinity-KDE3-with-autotools, this is easily dealt with like this:
export QMAKESPEC=/usr/share/Qt/mkspecs/linux-g++
export PATH=/usr/kde3/bin:$PATH
export MOC=/usr/kde3/bin/moc
export UIC_PATH=/usr/kde3/bin/uic
export
PKG_CONFIG_PATH=/usr/kde3/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/lib/pkgconfig
and the configure option --prefix=/usr/kde3: I also need a single
acinclude.m4.in hack to look for /usr/include/Qt instead of
/usr/include/qt.
For the cmake builds, everything is just about as simple: I just need to
add
export CMAKE_PREFIX_PATH=/usr/kde3
export
CMAKE_INCLUDE_PATH=/usr/kde3/include:/usr/kde3/include/tqt:/usr/include/dbus-1.0:/usr/kde3/include/libkrandr
and pass in
-DCMAKE_INSTALL_PREFIX=/usr/kde3 -DUIC_EXECUTABLE=/usr/kde3/bin/uic
-DQT_INCLUDE_DIR=/usr/include/Qt
and everything works: the cmake builds are excellently done. (Obviously
this is all dealt with automatically by my autobuilder scripts, which
also handle flipping to cmake as needed: I don't need to do any of this
by hand, perish the thought.)
But the autotools builds in kdenetwork et al in SVN head have become
terminally confused, even with extra hackery to force
-I/usr/kde3/include in front of the -include line that pulls in TQt
(which line is not consistently specified: it doesn't seem to be present
in the line below, for instance: I haven't figured out why yet).
--enable-closure does not help (not that I ever seemed to need that
pre-Trinity, but you recommended it so I tried it: no help). As this
makes clear...
libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../../.. -I/usr/kde3/include
-I/usr/include/Qt -I. -DQT_THREAD_SUPPORT -D__NO_STRING_INLINES -D__NO_MATH_INLINES
-D_LARGEFILE64_SOURCE -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-DNDEBUG -DNO_DEBUG -O2 -fpermissive -Wstrict-overflow=1 -g -gdwarf-4
-feliminate-dwarf2-dups -feliminate-unused-debug-types -fvar-tracking-assignments -O2
-pipe -ffast-math -D__NO_STRING_INLINES -D__NO_MATH_INLINES -D_LARGEFILE64_SOURCE
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions
-fno-check-new -fno-common -I/usr/kde3/include/tqt -fvisibility=hidden
-fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT hostprops.lo -MD -MP -MF .deps/hostprops.Tpo -c
hostprops.cpp -fPIC -DPIC -o .libs/hostprops.o
In file included from hostprops.cpp:18:0:
./hostprops.ui.h:10:29: error: no 'void HostProps::setModified()' member function
declared in class 'HostProps'
hostprops.cpp: In constructor 'HostProps::HostProps(QWidget*, const char*)':
hostprops.cpp:31:59: error: invalid use of incomplete type 'struct QGroupBox'
hostprops.h:18:7: error: forward declaration of 'struct QGroupBox'
hostprops.cpp:32:18: error: invalid use of incomplete type 'struct QGroupBox'
hostprops.h:18:7: error: forward declaration of 'struct QGroupBox'
hostprops.cpp:32:119: error: invalid use of incomplete type 'struct QGroupBox'
... uic (or rather, the uic postprocessing hackery) has gone mad and is
not including the right headers for the things that the .ui.h files will
need :( I tried to understand what was going on and my brain melted.
I tried to build a pre-TQtized kdenetworks and, well, that won't work
because the KDE public headers now require TQt. So it is 'Trinity
everywhere' or 'Trinity nowhere' and ne'er the twain shall meet.
I can provide some complete failing build logs if you like. (I just
didn't want to bomb the list with them.)
A task as quixotic as this one deserves encouragement. Besides, KDE3 is
a wonderful piece of work and it's worth keeping it running.
--
NULL && (void)
Tried that
(hence the patches sent earlier today). tqt, arts, kdelibs,
dbus-tqt and kdebase built after some patching, but when I hit
kdenetwork and tried to build it via autotools I got the FTBFS which
started this thread :( and comments from Robert that the SVN trunk of
the non-cmakeable modules is not buildable with autotools either at
present.
This is not correct. You can (and should) build the packages I mentioned
with CMake, and then proceed to build the remaining packages with
Autotools. Of course I am only mentioning this within
the context of
using the latest SVN sources; the older 3.5.12 release is only buildable
under Autotools, and is also restricted to working with autoconf < 2.63.
That's exactly what I thought (though actually the latest KDE from trunk
SVN built with autoconf 2.64 perfectly well when I did it last).
It seems that
the autotools machinery is getting something
wrong such that TQt is not being picked up properly, I'd guess. (Plainly
it works sometimes, because the SVN log contains recent mentions of
fixes of FTBFS errors: hence this report.)
I am actually running a full rebuild test as I write this, so if something
is not buildable I will find out about it soon. Otherwise, there is a
chance that something is different in your setup vs. my setup, and you may
need to pass additional configuration flags to the Autotools-dependent
Trinity packages. (btw, I think
what you're doing with Trinity is awesome. A parallel-
installable KDE3 eventually atop Qt4: it's what the KDE devs should have
done all along :) )
Thanks! Encouragement is always appreciated here. :)