hmm... rought instractions to reproduce:
- compile/install kviewshell
- clean the build directory
- try to build kdvi
it should fail because it cannot link to kviewshell-static. I see two solutions now:
- make kviewshell dynamically-linked
- install it as static lib to system
I like the first variant more, but it's rather small... I've wanted to see how it was made in autotools... seems it was dynamic but I'm not sure enough to make a bug report ...
Sounds like you are building separate app packages from tdegraphics. Have your tried to just build tdegraphics? If that works then try splitting tdegraphics into separate packages. Here are my tdegraphics configure options:
rm CMakeCache.txt 2>/dev/null mkdir -p ${TMP}/${PRGNAM}.build
cd ${TMP}/${PRGNAM}.build cmake $SOURCES_ROOT \ -DCMAKE_C_FLAGS:STRING="$CPUOPT" \ -DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \ -DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ -DMAN_INSTALL_DIR=${MANDIR} \ -DWITH_GCC_VISIBILITY=OFF \ -DWITH_T1LIB=ON \ -DWITH_PAPER=ON \ -DWITH_TIFF=ON \ -DWITH_OPENEXR=ON \ -DWITH_PDF=ON \ -DBUILD_KMRML=OFF \ -DBUILD_ALL=ON || exit 1
To build separate app packages, my thinking is first build a base tdegraphics package. Check CMakeLists.txt for the separate build options. In the build script set those options to OFF. Then build and install tdegraphics. That becomes the base package. Build scripts for individual apps will be the same with all build options OFF except for the specific app you are building and that option will be ON.
I do something similar to build a special tdebase docbook package. That way I can edit and update some of the tdebase user guides and build a very specific package of just those files.
For automake packages, the trick is to use the DO_NOT_COMPILE environment variable. In the sources will be text files named subdirs. Those text files are a good start for what text strings to use with the DO_NOT_COMPILE environment variable. Unfortunately, some of those files are missing in the Trinity sources. I keep copies of all the 3.5.10 packages and the subdirs text files are in those packages. Regardless, grepping the sources will provide examples of using that environment variable.
Note: When using autotools, be sure to always
regenerate the autoconf/automake files, as mentioned in section 3 of the wiki:
This regeneration doesn't work itself...
Correct, the build script needs to perform that. In my automake build scripts I run this:
LIBTOOLM4="/usr/share/aclocal/libtool.m4" LTMAINSH="/usr/share/libtool/config/ltmain.sh" echo "Running make clean (please be patient)..." make clean &>/dev/null cp -p "$LIBTOOLM4" admin/libtool.m4.in cp -p "$LTMAINSH" admin/ltmain.sh echo "Building..." echo make -f admin/Makefile.common || exit 1
Darrell