31 Oct
2012
31 Oct
'12
4:47 a.m.
It seems I discovered another bug in cmake files. And to be sure,
there it is and how to fix it, I need to compile it with autotools.
But when I'm trying to regenerate files I run into troubles.
What's wrong?
============================== LOG
========================================================
vm-gentoo-test-amd64 tmp # git clone
http://git.trinitydesktop.org/cgit/tdegraphics
Cloning into 'tdegraphics'...
vm-gentoo-test-amd64 tmp # cd tdegraphics/
vm-gentoo-test-amd64 tdegraphics # git submodule init
Submodule 'admin'
(http://system@scm.trinitydesktop.org/scm/git/tde-common-admin)
registered for path 'admin'
Submodule 'cmake'
(http://system@scm.trinitydesktop.org/scm/git/tde-common-cmake)
registered for path 'cmake'
vm-gentoo-test-amd64 tdegraphics # git submodule update
Cloning into 'admin'...
remote: Counting objects: 283, done
remote: Finding sources: 100% (283/283)
remote: Total 283 (delta 196), reused 283 (delta 196)
Receiving objects: 100% (283/283), 401.15 KiB | 97 KiB/s, done.
Resolving deltas: 100% (196/196), done.
Submodule path 'admin': checked out
'efdff81cd246d0737ecb1a82ef6fd588c0a6bc08'
Cloning into 'cmake'...
remote: Counting objects: 353, done
remote: Finding sources: 100% (353/353)
remote: Total 353 (delta 232), reused 353 (delta 232)
Receiving objects: 100% (353/353), 50.68 KiB, done.
Resolving deltas: 100% (232/232), done.
Submodule path 'cmake': checked out
'f1cea7f894713183e061fa6d2b69b05889a90a03'
vm-gentoo-test-amd64 tdegraphics # cp -Rpv $(find /usr/share -iname
libtool.m4) admin/libtool.m4.in
<</usr/share/aclocal/libtool.m4>> -> <<admin/libtool.m4.in>>
vm-gentoo-test-amd64 tdegraphics # cp -Rpv $(find /usr/share -iname
ltmain.sh) admin/libtool.m4.in
<</usr/share/libtool/config/ltmain.sh>> ->
<<admin/libtool.m4.in>>
vm-gentoo-test-amd64 tdegraphics # make -f admin/Makefile.common
*** automake (GNU automake) 1.11.6 found.
*** Creating acinclude.m4
*** Creating list of subdirectories
*** Creating Makefile.am
*** Creating configure.files
*** Creating configure.in
*** Creating aclocal.m4
acinclude.m4:7907: error: m4_defn: undefined macro: _AC_LANG
../../lib/autoconf/lang.m4:108: AC_LANG_POP is expanded from...
../../lib/autoconf/c.m4:448: AC_PROG_CC is expanded from...
/usr/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from...
/usr/share/aclocal/libtool.m4:69: LT_INIT is expanded from...
acinclude.m4:7907: the top level
autom4te-2.68: /usr/bin/m4 failed with exit status: 1
aclocal-1.11: /usr/bin/autom4te failed with exit status: 1
make: *** [cvs] Ошибка 1
============================== LOG
========================================================
BTW is it ok to ask for support on build issues here? or I'm supposed
to do it in trinity-users maillist?
31 Oct
31 Oct
6:18 a.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
It seems I discovered another bug in cmake files. And
to be sure,
there it is and how to fix it, I need to compile it with autotools.
But when I'm trying to regenerate files I run into troubles.
What's wrong?
I am using cmake in my tdegraphics builds and have been since the module was ported to
cmake. So let's focus on why cmake isn't working. :)
Note: When using autotools, be sure to always regenerate the autoconf/automake files, as
mentioned in section 3 of the wiki:
http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild
BTW is it ok to ask for support on build issues here?
or I'm supposed
to do it in trinity-users maillist?
This list is appropriate.
Darrell
6:43 a.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
2012/10/31 Darrell Anderson <humanreadable(a)yahoo.com>om>:
I am using cmake in my tdegraphics builds and have
been since the module was ported to cmake. So let's focus on why cmake isn't
working. :)
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 ...
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...
4:34 p.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
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:
5:33 p.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
2012/10/31 Darrell Anderson <humanreadable(a)yahoo.com>om>:
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
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...
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.
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...
As I mentioned somewhere, I'm doing a gentoo packaging , it means I'm
writing ebuilds, special build scripts which end users runs on their
machines... and it is much more easy to manage them if they will be
building as separate packages...
Note:
When using autotools, be sure to always
regenerate the autoconf/automake files, as
mentioned in
section 3 of the wiki:
6:44 p.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
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
1 Nov
1 Nov
4:50 a.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
2012/10/31 Darrell Anderson <humanreadable(a)yahoo.com>om>:
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...
2 Nov
2 Nov
12:31 a.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
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
9:29 p.m.
New subject: [trinity-devel] [tdegraphics][autotools] regenerate Autoconf/Automake files
found there was the problem... just copied wrong files... >_<
cp -Rpv $(find /usr/share -iname libtool.m4) admin/libtool.m4.in
cp -Rpv $(find /usr/share -iname ltmain.sh) admin/libtool.m4.in
4200
days inactive
4202
days old
8 comments
2 participants
participants (2)
-
Darrell Anderson -
Fat-Zer