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 > [EMAIL PROTECTED] > 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 _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
