libjava holding regression tester hostage

Fri Mar 25 20:12:00 GMT 2005

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.