[GNU Crypto] Re: request for comments (long)

[Tom Tromey]

>>>>> "Raif" == Raif S Naffah <<address@hidden>(by way of Raif S. Naffah 
>>>>> <address@hidden>)> 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
Raif> implementation).

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> BAR
Raif> !gnu.crypto.cipher.BaseCipherTestCase
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
Raif>  complicated

>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.

Tom