This is the mail archive of the
mailing list for the Mauve project.
Re: request for comments (long)
- From: Tom Tromey <tromey at redhat dot com>
- To: raif at fl dot net dot au
- Cc: Mauve <mauve-discuss at sources dot redhat dot com>, GNU Crypto <gnu-crypto-discuss at gnu dot org>
- Date: 10 Dec 2002 15:30:04 -0700
- Subject: Re: request for comments (long)
- References: <email@example.com>
- Reply-to: tromey at redhat dot com
>>>>> "Raif" == Raif S Naffah <<firstname.lastname@example.org>(by way of Raif S. Naffah <email@example.com>)> writes:
Raif> i'm trying to add Mauve regression tests to the GNU Crypto project.
Raif> currently regression tests are done with JUnit (framework and
Don't let me discourage you, but in the past there's been a fair
amount of discussion on this list along the lines of "let's convert
Mauve to use JUnit" and "Mauve's test framework is a pain".
Given that, I'm curious to know why you'd want to convert...
Raif> looking at how Mauve works, it seems that the process (very
Raif> roughly) is as follows:
Raif> [ ...]
Your understanding seems correct.
Raif> II. the 'choose' script seems to consider the value passed to KEYS;
Raif> e.g. foo as a Tag to look for in the source files, _in addition_ to
Raif> any other Tag that may be used in the '// Tags: ' line. in other
Raif> words, if in my 'mauve-gnu-crypto' file i have the following lines:
Raif> and in gnu/testlet/gnu/crypto/cipher i have a file, say TestOfSquare,
Raif> that has the following line:
Raif> // Tags: gnu-crypto
Raif> it will get chosen by 'choose'.
In this case you're running with `KEYS=gnu-crypto'? That behavior
seems a bit unintentional to me.
Raif> III. when i tried to use the exclusion mechanism --prefix the name of a
Raif> class with ! after chopping off the gnu.testlet prefix-- the class,
Raif> when it contains the '// Tags: xxx' line is always chosen.
I don't follow :-(.
Raif> IV. the mechanics of configuring Mauve, and GNU Crypto, are
>From time to time I've considered simply remove the auto* machinery
and going with something simpler. In this environment it would
probably be appropriate. However, as things have always worked
adequately for my needs, I've never had a strong motivation to do
anything about it.
Raif> another approach is to import the Mauve base classes and scripts into
Raif> GNU Crypto, and handle the lot with the same toolchain. the problem
Raif> with this approach is that every time an enhancement is made to Mauve,
Raif> the same has to be adopted for its twin in GNU Crypto.
Raif> is there a better way that we can use today?
Maybe not :-(. We're definitely open to suggestions and patches
improving the situation.
For libgcj we just have our test harness run Mauve's own configure and
build. However, as you point out this is a pain since the test code
is a different project which must somehow be pointed to.