Re: coreutils-5.1.3 released: bug-fix-only, candidate for stable 5.2.0

[Michael Elizabeth Chastain]

mec>        rm -f 
/house/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.am 
/house/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.amt
mec>        sed -n '1,/^##test-files-begin/p'  > 
/house/chastain/coreutils/coreutils-5.1.3/tests/wc/Makefile.amt
mec>
mec>   This is a bug in tests/wc/Makefile.in.  $< is defined only for
mec>   inference rules and .DEFAULT, not for explicit rules.  See:

jim> Many of the coreutils Makefiles use that construct, and it's
jim> ok as long as their rules rarely need to be run.
jim> Maybe you accidentally modified tests/Makefile.am.in, wc/Test.pm,
jim> or another dependent?  Otherwise, that rule shouldn't trigger.

No, I am running out of a pristine source directory unpacked straight
from the tarball, with nothing else done to it first.  I don't
re-use the source dir from one configuration to another -- every run
starts with a fresh 'tar xjf ...'.

That use of $< in tests/wc/Makefile.am does not conform to Single Unix
Specification v3.  How about just doing this and conforming:

  sed -n '1,/^##test-files-begin/p' $(srcdir)/../Makefile.am.in > address@hidden

> The coreutils INSTALL file says that you need a version of `make' that
> supports the `VPATH' variable if you do non-srcdir builds.  I suspect
> that applies in this case.

You are right.  Okay, I will stick to srcdir builds when I use hpux make
and osf make.

Anyways, if you want to put up another tarball, I'll be happy to churn
it again.

Michael C