Re: Mauve patches.

["C. Brian Jones" <cbj at gnu dot org>]

Thanks for your comments Anthony!

On Fri, 2004-04-16 at 16:23, Anthony Green wrote:
> 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.

I want to be able to run it against gcj, gij, kissme, kaffe, sablevm,
jamvm, jdk, etc.  Not really all at once, just depending on what I'm
using at the time.  I don't think the clean, reconfigure, make dance is
appropriate for this task.

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

Nothing wrong with that, but it wouldn't hurt to provide something out
of the box would it?

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

It's pretty nasty.  I have a feeling it turns some people away when it
isn't very clear how to set it up, run it, add or modify a test, and
re-run it.

> > * 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?

The intention is for standalone use.  Although one could probably keep
the Makefile.am/configure as-is, it would clean things up considerably
to move such their current functionality into a re-usable script.

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

Right, I have a feeling that to do what I want I'd have to modify some
part of this though probably not a great deal as long as tests can still
be executed without installing.

Brian

Attachment: signature.asc
Description: This is a digitally signed message part