Re: Mauve patches.

[Anthony Green <green@redhat.com>]

On Sun, 2004-04-11 at 21:12, C. Brian Jones wrote:
> * Cannot be installed (packaged, used repeatedly for various cases from
> same install)

I'm not sure why you would want to "install" mauve.  I guess I'm too
used to how we use Mauve with libgcj.

> * No integrated pass/fail/expected/unexpected summary

The Big Idea was that different projects would have different QA
infrastructure requirements, which would be satisfied by writing system
specific test harnesses.  So, for instance, we have a dejagnu specific
test harness in the libgcj source tree.

> * Repeated executions require knowing inner workings of
> various scripts

Again, this may be a result of our assumption that the core Mauve
infrastructure would be augmented by project specific infrastructure.

> * Integration of additional libraries difficult at best
> * Integration of VM specific tests also difficult
>  
> Solutions
>          
> * Change configure script to be installation oriented, similar for
> Makefile.am (started this already)
> * New script(s) for running mauve to compile, execute, report
> results (consider using dejagnu)
> 	* Specify java compiler at runtime
>         * Specify vm at runtime
>         * Specify temporary directory at runtime
> 	* Specify additional libraries/resources at runtime
> 	* Specify additional tests at runtime

Are you doing this for a specific system, or for stand-alone Mauve
usage?

> Basically all the cruft and gorp in configure.in, Makefile.am, choose,
> etc. gets done over.  The TAGS system is broken, it doesn't allow one to
> specify that a particular test is only valid for 1.1, 1.2, 1.3 and not
> 1.4+, essential to handle deprecated methods that eventually get
> removed.  I have no problem doing this work, my problem is all the
> people that depend on the current directory structure, build process,
> etc. that will scream if something is changed.  Anyway I have started
> the work, when I have a patch I'll let the list review.  Don't hold your
> breath, I'm slow sometimes.  :)

FWIW, I don't feel strongly about the stand-alone Mauve infrastructure
as long as the libgcj usage doesn't break (see
gcc/libjava/testsuite/libjava.mauve).

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.