classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Method of executing Mauve


From: Brian Jones
Subject: Re: Method of executing Mauve
Date: 07 Nov 2002 23:28:38 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Mark Wielaard <address@hidden> writes:

> Hi,
> 
> On Wed, 2002-11-06 at 04:48, Brian Jones wrote:
> > Someone mentioned they had a method of executing Mauve that would
> > appropriately time out and kill the bad VM.  I'm guessing some use of
> > expect/tcl here.  If there is an example I could look at that would be
> > great.
> 
> See the following. It is a shell script that can be integrated with the
> rest of the Mauve source tree. Maybe I should just make it part of
> Mauve.
> 
> http://sources.redhat.com/ml/mauve-discuss/2002-q3/msg00019.html

Fixed the URL.  It should be simpler to configure/use Mauve.  I don't
like having to export JAVA, JAVAC, before configure/make... this
choice should be defined at runtime anyway instead of configure time.

I currently find myself completely ignoring the Mauve machinery
(except the choose script) to do my nightly tests (not yet running)
which doesn't seem right to me.  

I also really dislike the gcj machinery requiring a test be limited to
a single .java file; it forces a certain structure upon tests and
limits reuse of common code... the different machinery also means that
making far reaching changes is more difficult... it isn't enough to
make the Mauve machinery better but to keep the gcj machinery working.

Some requirements for Mauve machinery seem to be:

* able to set java at runtime (of test harness, not configure)
* able to choose javac (.java to bytecode, .java to native) at runtime
* choice of tests at runtime
* test harness can execute compiler/vm separately for each test
* test harness can kill test execution (vm) after a general timeout
* test harness can optionally clean up after itself (tests written to
  make this easier, follow some standard)

Btw, I think the current tag system is inadequate.  To express that a
particular set of tests is valid in JDK 1.1, deprecated in 1.2, 1.3,
and invalid for 1.4+ the user must construct the key file to
specifically exclude the tests in 1.4+ testing, ideally the user would
just specify JDK1.4.

Brian
-- 
Brian Jones <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]