On 20 Jul 2011, Timothy Pearson outgrape: >> 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. Ah. Well, it's not working for me then :) > 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. 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.) >> (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. :) 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)