From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4572 invoked by alias); 16 Apr 2004 20:23:14 -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 4555 invoked from network); 16 Apr 2004 20:23:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Apr 2004 20:23:13 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GKNDJW000478 for ; Fri, 16 Apr 2004 16:23:13 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GKN9j11065; Fri, 16 Apr 2004 16:23:10 -0400 Received: from to-dhcp28.toronto.redhat.com (to-dhcp28.toronto.redhat.com [172.16.14.128]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i3GKN8cU024142; Fri, 16 Apr 2004 16:23:08 -0400 Subject: Re: Mauve patches. From: Anthony Green To: cbj@gnu.org Cc: Thomas Zander , David Lichteblau , mauve-discuss@sources.redhat.com In-Reply-To: <1081743135.3175.18.camel@lyta.haphazard.org> 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> Content-Type: text/plain Organization: Red Hat, Inc. Message-Id: <1082146987.3559.71.camel@escape> Mime-Version: 1.0 Date: Fri, 16 Apr 2004 20:23:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q2/txt/msg00043.txt.bz2 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 Red Hat, Inc.