From: "C. Brian Jones" <cbj@gnu.org>
To: Anthony Green <green@redhat.com>
Cc: mauve-discuss@sources.redhat.com
Subject: Re: Mauve patches.
Date: Fri, 16 Apr 2004 22:57:00 -0000 [thread overview]
Message-ID: <1082156245.3175.49.camel@lyta.haphazard.org> (raw)
In-Reply-To: <1082146987.3559.71.camel@escape>
[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-04-16 22:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-06 7:55 Thomas
2004-04-06 8:47 ` Michael Koch
2004-04-08 19:34 ` Thomas Zander
2004-04-08 19:50 ` Michael Koch
2004-04-08 19:58 ` Andrew Haley
2004-04-11 6:48 ` Thomas Zander
2004-04-11 12:22 ` David Lichteblau
2004-04-11 17:20 ` Thomas Zander
2004-04-11 18:57 ` David Lichteblau
2004-04-11 19:37 ` Thomas Zander
2004-04-12 4:12 ` C. Brian Jones
2004-04-16 20:23 ` Anthony Green
2004-04-16 22:57 ` C. Brian Jones [this message]
2004-04-13 13:22 ` Andrew Haley
2004-04-13 13:55 ` Thomas
2004-04-13 14:30 ` Andrew Haley
2004-04-13 17:14 ` Thomas Zander
2004-04-13 17:45 ` Andrew Haley
2004-04-13 18:59 ` Thomas Zander
2004-04-14 9:56 ` Andrew Haley
2004-04-14 0:09 ` Bill McFadden
2004-04-15 22:56 ` Mark Wielaard
2004-04-17 14:45 ` Thomas Zander
2004-04-11 15:56 ` Archie Cobbs
2004-04-15 21:10 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1082156245.3175.49.camel@lyta.haphazard.org \
--to=cbj@gnu.org \
--cc=green@redhat.com \
--cc=mauve-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).