Re: "make check" failure [with "." at beginning of PATH]

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Building coreutils-6.10 on a Linux/x86 machine fails like this for me:
>
> $ ./configure --prefix=/packages/gnu CPPFLAGS=-Wall
> $ make 2>&1 | tee log1
> $ make check 2>&1 | tee log2
> ...

Thanks for the report.
I suspect there is something unusual about this system or your environment,
since this is the first such failure report I've seen for 6.10.

> Making check in misc
> make[2]: Entering directory `/build/coreutils-6.10/tests/misc'
> make  check-TESTS
> make[3]: Entering directory `/build/coreutils-6.10/tests/misc'
> make[4]: Entering directory `/build/coreutils-6.10/tests/misc'
> /packages/gnu/bin/mkdir: cannot create directory `': No such file or directory
...
> /packages/gnu/bin/mkdir -p "$(dirname help-version.log)" || exit; \
...
> What is the fifth part of this command meant to be? "$(dirname ...)" ??
> It comes from build-aux/check.mk. It's certainly not meant as a GNU make
> expression, since you don't normally assume GNU make. So it's a shell
> expression.

Right.

> There are two problems:
> 1) Backquotes should be used instead of bash-specific syntax.

Since November, tests and infrastructure can use POSIX-shell syntax
like $() on most systems.  See the posix-shell gnulib module and
this change by Paul Eggert:

  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1379ed974

> 2) 'dirname' refers to the program in PATH. My $PATH starts with ".". "." is

Ah ha!  *That* is the problem.
Don't put "." in your PATH at all, and especially not at the front.

>    the tests/misc directory. tests/misc/dirname is a test which prints nothing
>    to stdout, hence `./dirname help-version.log` is empty.

All test scripts are run in an environment in which
PATH never starts with ".".  There, PATH starts with $(abs_top_builddir)/src
which contains the just built dirname executable.
However, the build-related snippet you quoted is run outside that
environment (to set it up, in fact), and expects a sane PATH.

If you see an easy, clean fix, then great.  Otherwise, I wouldn't
worry about it: the upcoming release of automake will provide similar
capabilities, and then I'll be able to remove most of build-aux/check.mk.