hmm... rought instractions to reproduce:

1. compile/install kviewshell
2. clean the build directory
3. try to build kdvi

it should fail because it cannot link to kviewshell-static. I see two solutions now:

1. make kviewshell dynamically-linked
2. 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

Now I understand why nobody have seen so many errors in CMakefiles before me and I've got so a lot to fix =)... It's all because everybody uses such way to build it...

Please stay on your path. :) For a long time I have wanted to see this happen in Trinity. As the problem basically reduces to packaging, you will be blazing a nice trail. From those efforts I can adapt my own (Slackware) build scripts and the result will be, hopefully, a nice how-to on the wiki.

I don't doubt there are likely bugs in the build process when splitting packages that require nominal patching, but I think we first need to ensure you can build the complete package. :)

In the mean time, as I am unfamiliar with gentoo practices, I recommend first focusing on building the complete package. Get that working to provide you a known base. Thereafter start splitting packages into smaller packages.

Take a look into my log in the first message (it's corrupted by mail sysyem but still readable, here is the normal one: https://gist.github.com/3988463 )... I'm doing the same things...

I'm not an automake guru, but my first thought was what version of automake are you using?

Then I thought this probably is an irrelevant question. :) All of the cmake and admin directories in each module are clones from respective masters in the upstream GIT repository. Patching any of those files means patching only the master copy. Local copies of the repo will not keep the links to the master directories, at least that does not happen on my system. There is a script that is run at the upstream servers to keep everything in sync. In summary this means if one build fails then others are likely to fail too because the base files are all clones.

A key file in this explanation is admin/cvs.sh:58:

case $AUTOMAKE_STRING in automake*1.6.* | automake*1.7* | automake*1.8* | automake*1.9* | automake*1.10* | automake*1.11* | automake*1.12*)

To my knowledge that covers all expected versions of automake. Hence my statement that the question probably is irrelevant. :)

Darrell

I've got: app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r3

I feel I'm totally lame in autotools...

That makes two of us. :(

With that said, as tdegraphics was ported to cmake long ago and nobody is complaining, focusing on building with cmake likely would be more productive. With that said, here are my old automake configuration options for tdegraphics:

============================== CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --mandir=${MANDIR} \ --with-qt-dir=${QTDIR} \ --with-qt-includes=${QTDIR}/include \ --with-qt-libraries=${QTDIR}/lib \ --with-xinerama \ --with-poppler \ $DEBUG_AUTOTOOL_OPT \ --enable-closure ==============================

And now that I have shared those old settings, I immediately wonder whether you are using the --enable-closure option? Please add that option and see what happens. There is a snippet in the wiki instructions addressing the need for that configure option in some automake build scripts. I won't pretend to know what the option accomplishes. I do know that the option solves build failures with the packages listed in the wiki. :)

Darrell