Re: make check failures

[Stefano Lattarini]

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 address@hidden
> =====================================
> 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