Re: [trinity-devel] Re: tdelibs v3.5.13 doesn't build!

I don't know how much I can help here. :) I believe the reference to me might be to the time I had to troubleshoot certain build failures, which eventually I discovered were caused be setting the $CPLUS_INCLUDE_PATH environment variable. Setting the $CPLUS_INCLUDE_PATH in the build environment prevents pkg-config from running properly. The moment I removed that export command in my master script, the cmake TQT_INCLUDE_DIRS internal variable began populating automatically. First and foremost, I use a chroot environment to build Trinity packages. In that environment I do not have KDE3, KDE4, or Qt4 installed. For my usability testing I might have any or all of those three installed, but not in my build environment. An alternative to a chroot environment is a virtual machine or a separate physical machine. The idea is to have a clean but full distro installation minus anything that will cause conflicts. For example, proprietary video drivers should never be installed in a Trinity build environment. For my usability testing I do not use my chroot build environment. Instead I use virtual machines and separate partitions on physical machines. I keep my usability testing environments separate from my build environment. As mentioned in the wiki, I install all Trinity packages, including (T)Qt3, to /opt/trinity except tqtinterface. I install tqtinterface to /usr. To avoid conflicts with Qt4, in all build scripts still using automake, I explicitly define where to find Qt3 files: --with-qt-dir=${QTDIR} --with-qt-includes=${QT_INCLUDE_DIR} --with-qt-libraries=${QTDIR}/lib The cmake builds do not need those same explicit declarations (those locations are now built into the Trinity cmake build process). Of course, in my build environment I remove the Qt4 package and avoid conflicts altogether. However, I maintain these explicit declarations as habit because originally one of the project goals was to build certain packages with Qt4 support. That is not the case today, but I maintain the explicit declarations. A clean and separate build environment more or less avoids all of these issues. I explicitly define in my master build script certain environment variables, such as $PATH. The search path must include the Trinity bin directory first in the $PATH variable, and not appended last as is standard practice. With building (T)Qt3, no related build environment variables are yet set because that is the first package built in the entire build sequence. However, in my (T)Qt3 build script I explicitly declare two environment variables because the Qt3 build process dependes upon its own binaries to build: export QTDIR=`pwd` if [ -n "$LD_LIBRARY_PATH" ]; then export LD_LIBRARY_PATH=${QTDIR}/lib:$LD_LIBRARY_PATH else export LD_LIBRARY_PATH=${QTDIR}/lib fi export PATH=${QTDIR}/bin:$PATH As much as building the entire package set in automated mode is desirable, I have not figured out a way to do so until I have both (T)Qt3 and tqtinterface built. Thereafter I can build all other packages in automated mode. Therefore I first build and install (T)Qt3. Then I build and install tqtinterface. Thereafter I build everything else in automated mode. After I have (T)Qt3 and tqtinterface installed, my master build script explicitly sets the following environment variables: $PKG_CONFIG_PATH $QTDIR $QT_INCLUDE_DIR $QT_LIB_DIR $LD_LIBRARY_PATH $PATH I am in the process today of building everything from scratch from GIT for the first time in a few weeks. We'll see how that goes by the end of the day. I hope something here helps. :) Darrell