This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
libjava holding regression tester hostage
- From: Mike Stump <mrs at apple dot com>
- To: java at gcc dot gnu dot org
- Cc: gcc-regression at gcc dot gnu dot org
- Date: Fri, 25 Mar 2005 12:11:45 -0800
- Subject: libjava holding regression tester hostage
The libjava failure:
FAIL: Array_3 -O3 execution - bytecode->native test
Running
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.loader/
loader.exp ...
Running
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.mauve/
mauve.exp ...
Running
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.verify/
verify.exp ...
=== libjava Summary ===
# of expected passes 3786
# of unexpected failures 1
# of expected failures 10
# of untested testcases 9
make[3]: *** [check-DEJAGNU] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check-target-libjava] Error 2
appears to be holding the regression tester hostage. :-( This is
stupid/bad. I researched it, and it does this because automake
generates:
libjava/testsuite/Makefile.in:
check-DEJAGNU: site.exp
srcdir=`$(am__cd) $(srcdir) && pwd`; export srcdir; \
EXPECT=$(EXPECT); export EXPECT; \
runtest=$(RUNTEST); \
if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \
l='$(DEJATOOL)'; for tool in $$l; do \
$$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS)
$(RUNTESTFLAGS); \
done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
but, this is wrong, it doesn't have a - on the front of the runtest
command, so it propagates `normal' testsuite failures all the way up to
the return status of make, which, we decided a while ago not to do.
Now, if libjava always just works, maybe we could take a pass on it...
but, if it doesn't, we should find some way to ignore the return code
from runtest.