This is the mail archive of the
mailing list for the Mauve project.
Re: Method of executing Mauve
- From: Mark Wielaard <mark at klomp dot org>
- To: Brian Jones <cbj at gnu dot org>
- Cc: GNU Classpath <classpath at gnu dot org>,Mauve Discussion Mailing List <mauve-discuss at sources dot redhat dot com>
- Date: Sat, 9 Nov 2002 15:58:00 +0100
- Subject: Re: Method of executing Mauve
- References: <email@example.com> <1036694578.1177.118.camel@elsschot> <firstname.lastname@example.org>
(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 <email@example.com> 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