On Tuesday 24 May 2011, Graham Reitz wrote:
> After a successful build, make check yields:
>
> =====================================
> 628 of 650 tests failed
>
Ouch.
> (79 tests were not run)
> See tests/test-suite.log
> Please report to bug-autom...@gnu.org
> =====================================
> make[3]: *** [test-suite.log] Error 1
> make[2]: *** [check-TESTS] Error 2
> make[1]: *** [check-am] Error 2
> make: *** [check-recursive] Error 1
>
Could you please post the resulting `test-suite.log'? It's hard
to tell what's going on without more information ...
>
> Configure:
> ./../../gnu/automake/automake-1.11/configure \
> --prefix=$HOME/root/usr/local \
> AUTOCONF=$HOMEt/root/usr/local/bin/autoconf \
> AUTOM4TE=$HOMEt/root/usr/local/bin/autom4te
>
> configure is invoked from separate build directory (pointing this out
> as some gnu source builds insist configure be called from outside the
> source directory and others from inside).
>
Automake's build system should work in both ways. If it doesn't, I'd
consider that a bug, and I'd be glad to be informed about it.
> I suspect the make check errors have something to do with needing
> a dirlist (as Daniel pointed out).
>
I don't think so; for what concerns the Autoamke testsuite, the only
side effect of lacking a `dirlist' is that the test scripts won't be
able to find third-party macros (e.g., LT_INIT or AM_GNU_GETTEXT) if
the third-party packages providing them (e.g., libtool or gettext) are
not installed under the same $(prefix) used to configure the Automake
being tested (in your case, `$HOME/root/usr/local'). If this is the
case, some tests might be SKIP'd -- but no test is expected to fail
in this situation. If it does, that's a bug of the testsuite.
> In this case, where make check is run from the build directory
> outside the source directory, where should the dirlist file go
> (what is considered acdir)?
>
You shouldn't need to provide any `dirlist' file. The Automake testsuite
should automatically and *transparently* provide a wrapper script that
takes care of redefining acdir and making all the required m4 files and
perl modules available to aclocal; for example, on my system, I have:
$ cat ~/src/automake/tests/aclocal-1.11
#!/bin/sh
# tests/aclocal-1.11. Generated from aclocal.in by configure.
# Be Bourne compatible
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
fi
perllibdir="/home/stefano/src/automake/lib:/home/stefano/src/automake/lib"
export perllibdir
# Most of the files are in $srcdir/../m4. However amversion.m4 is
# generated in ../m4, so we include that directory in the search path too.
exec "/home/stefano/src/automake/aclocal" $ACLOCAL_TESTSUITE_FLAGS \
-I "/home/stefano/src/automake/m4"
"--acdir=/home/stefano/src/automake/m4" \
${1+"$@"}
In case you are interested to learn about the `dirlist' file, and more
generally about how aclocal searches for m4 macros and files, you might
take a look at this:
<http://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html>
Regards,
Stefano
