Re: JUnit integration

[Tom Tromey <tromey@redhat.com>]

>>>>> "graydon" == graydon hoare <graydon@redhat.com> writes:

graydon> these are attached. but the more general question -- the next logical
graydon> step in my mind -- is whether to start merging mauve into classpath so
graydon> it configures and builds "naturally" as part of the day-to-day
graydon> development cycle on classpath (using the classpath build dir,
graydon> compiler and VM selection, for example, and running as the nominal
graydon> "make check" for classpath). I'm wondering how taboo an idea that is,
graydon> whether anyone would mind if I had a go at it.

First, different VMs use Classpath differently.  So this may matter.

Second, traditionally Mauve hasn't required any copyright assignments
of any sort.  Collecting those now would be hard to impossible (e.g.,
we got a bunch of tests from HP years back, no clue who to contact
about those).  So it isn't clear Mauve meets GNU requirements for
checkin...

Third, it is useful to be able to run Mauve against non-Classpath
JVMs, in particular the Sun JVM.  This lets us do compatibility
testing; in fact an item on my infrastructure to-do list is to run
Mauve against the JDK nightly and compare the results, to see if we're
getting bad tests.


Anyway, those are issues, potential or otherwise.  I definitely agree
that making it easier to run Mauve against Classpath changes would be
helpful.

For libgcj we "solved" this problem by having some wrapper code in the
test suite.  Many libgcj developers probably don't run this regularly
though :-(.

Tom