Re: Method of executing Mauve

Re: Method of executing Mauve

[Mark Wielaard]

Hi,

(fixed mailinglist address sourceware.cygnus.org seems to have gone)

On Thu, Nov 07, 2002 at 11:28:38PM -0500, Brian Jones wrote:
> Mark Wielaard <mark@klomp.org> 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 agree that it isn't the easiest build machinery, but I actually like the
way you can use one source directory and send up different build directories
for the different java libraries, VM and compiler combinations.
You can run each test individually though by using something like:

echo gnu.testlet.java.some.test | \
  SomeVM -bootclasspath SomeClassLib gnu.testlet.SimpleTestHarness

(This assumes you have used the choices script to actually compile the class
with SomeCompiler :)

My script referenced above does make a couple of these things easier, but
I don't know how portable it is (it works for me with bash).

> 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.

You can use multiple files for a test. You just have to make sure that
a test lists all source files in the "// Uses: " comment. It would be nice
though if you could list source files from different packages though.
 
> 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.

On a related note, we should also add a tag "needs internet connection" since
some tests can onlt succeed when you can access some (random) machines on
the net.

Cheers,

Mark

Re: Method of executing Mauve

[Tom Tromey]

>>>>> "Brian" == Brian Jones <cbj@gnu.org> writes:

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

I don't think these choices can be made at runtime.  The problem is,
not every compiler may be able to compile the whole package and not
every runtime may have every class.  For instance, when compiling and
running against classpath, you must omit javax.naming tests -- but
these work fine with gcj.

Brian> Btw, I think the current tag system is inadequate.

There was a long-ish discussion of Mauve test harness inadequacies
earlier this year.  The real problem seems to be lack of time to
address them.  I myself have neither time nor interest; the current
system works fine for my needs.  Mostly that is because I never run
Mauve by hand, but instead let the libgcj test suite handle it for me.

Tom