From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3301 invoked by alias); 27 Nov 2003 04:34:13 -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 3286 invoked from network); 27 Nov 2003 04:34:12 -0000 Received: from unknown (HELO piglet.dstc.edu.au) (130.102.176.1) by sources.redhat.com with SMTP; 27 Nov 2003 04:34:12 -0000 Received: from dstc.edu.au (credence.dstc.edu.au [130.102.177.137]) by piglet.dstc.edu.au (8.12.10/8.12.10) with ESMTP id hAR4XZYd007924; Thu, 27 Nov 2003 14:33:36 +1000 (EST) Message-Id: <200311270433.hAR4XZYd007924@piglet.dstc.edu.au> To: graydon hoare cc: mauve-discuss@sources.redhat.com Subject: Classpath / Mauve integration In-Reply-To: Message from graydon hoare of "26 Nov 2003 21:50:13 EST." <874qwqjziy.fsf@dub.venge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 2003 04:34:00 -0000 From: Stephen Crawley X-Scanned-By: MIMEDefang 2.38 X-SW-Source: 2003-q4/txt/msg00004.txt.bz2 Hi Graydon, This is a response to two of your recent emails to 'classpath' and 'mauve-discuss' respectively. in a 'mauve-discuss' email, graydon@redhat.com said: > the next logical step in my mind -- is whether to start merging mauve > into classpath so it configures and builds "naturally" as part of the > day-to-day development cycle on classpath (using the classpath build > dir, compiler and VM selection, for example, and running as the > nominal "make check" for classpath). I'm wondering how taboo an idea > that is, whether anyone would mind if I had a go at it. I'm not sure I understand how you propose to do this 'merge', but here are some (IMO) no-nos. 1) Don't merge the Mauve source tree into the Classpath source tree. [I don't think you intended to but ...] 2) Don't make the Mauve config environment dependent on Classpath. If the Mauve config environment is 'aware' of Classpath, it should also work if Classpath isn't there. 3) Don't make the Classpath config/build environment dependent on Mauve. If the Classpath config/build environment is 'aware' of Classpath, it should also work if Mauve isn't there. I also have doubts as to whether adding a 'make check' to Classpath will work for most VMs that use Classpath. In many cases, Classpath does not currently 'know' anything about the 'client' VM; e.g. Kissme & SableVM. In the case of Kissme, Mauve integration works as follows. The Kissme autoconf setup has some magic to find the Classpath sandbox and (optionally) the Mauve sandboxes. The locations of these sandboxes are then expanded into the relevant Makefiles and scripts. Targets are provided in the Kissme makefile to configure Mauve for Kissme testing, and to run a regression tests using the Kissme VM. All of this is done without modifying either the Mauve or Classpath source trees to be aware of Kissme. In a 'classpath' email, graydon@redhat.com said: > my gut feeling (I don't mean to be insulting or dismissive, just > observing) is that few people -- and progressively fewer as time > passes -- will have a use for mauve outside testing classpath. if > they're a proprietary vendor, they'll buy a sun compatibility kit; > everyone else seems, from my limited perspective, to be slowly coming > around to the benefits of just throwing their weight behind classpath. It depends on what you mean by "have a use for mauve outside testing classpath". I use Mauve to test Kissme, but I do this "outside of Classpath" in the sense that I run the tests from the Kissme build environment. [See above.] More generally, testing against Mauve should be relevant to all Java implementors, whether or not they use the Sun JCK testsuite. While Mauve and the JCK tests do largely overlap, there will inevitably be Mauve testcases that cover aspects that JCK testcases don't cover. Compatibility of Java implementations in these aspects is of interest to Java developers, even if vendors don't care. Hence, there is a clear case for keeping Mauve largely independent of Classpath. -- Steve