From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5139 invoked by alias); 16 Apr 2004 22:57:29 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 5130 invoked from network); 16 Apr 2004 22:57:29 -0000 Received: from unknown (HELO ms-smtp-03-eri0.southeast.rr.com) (24.25.9.102) by sources.redhat.com with SMTP; 16 Apr 2004 22:57:29 -0000 Received: from [10.0.0.2] (rdu57-9-048.nc.rr.com [66.57.9.48]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i3GMvPs1028703; Fri, 16 Apr 2004 18:57:26 -0400 (EDT) Subject: Re: Mauve patches. From: "C. Brian Jones" Reply-To: cbj@gnu.org To: Anthony Green Cc: mauve-discuss@sources.redhat.com In-Reply-To: <1082146987.3559.71.camel@escape> References: <200404060956.14298.zander@javalobby.org> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <200404112136.52657.zander@javalobby.org> <1081743135.3175.18.camel@lyta.haphazard.org> <1082146987.3559.71.camel@escape> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xXU2Ww7IAQ3FnMf1W/6y" Message-Id: <1082156245.3175.49.camel@lyta.haphazard.org> Mime-Version: 1.0 Date: Fri, 16 Apr 2004 22:57:00 -0000 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-SW-Source: 2004-q2/txt/msg00045.txt.bz2 --=-xXU2Ww7IAQ3FnMf1W/6y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 3265 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) >=20 > 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 >=20 > 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 >=20 > 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 > >=20=20 > > Solutions > >=20=20=20=20=20=20=20=20=20=20 > > * 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 >=20 > 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. :) >=20 > 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 --=-xXU2Ww7IAQ3FnMf1W/6y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAgGTUcEcmdY33uzYRAmIiAJ9XLVR5WBJrhwNmu9Vpi6TWyTOVwgCgpc87 HdloEh/R8oEiJlNNSvxEQaU= =/VK/ -----END PGP SIGNATURE----- --=-xXU2Ww7IAQ3FnMf1W/6y--