This is the mail archive of the
mailing list for the Mauve project.
Re: Mauve patches.
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
> * 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
> 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
Anthony Green <firstname.lastname@example.org>
Red Hat, Inc.