gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNU Crypto] request for comments (long)


From: Raif S. Naffah
Subject: [GNU Crypto] request for comments (long)
Date: Mon, 9 Dec 2002 19:56:44 +1100
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello there,

i'm trying to add Mauve regression tests to the GNU Crypto project.  
currently regression tests are done with JUnit (framework and 
implementation).  the plan is to port/convert those tests to Mauve.  
this is an invitation for people who (a) have experienced the same 
situation, and/or (b) are experienced users of Mauve, to help us with 
this process.


looking at how Mauve works, it seems that the process (very roughly) is 
as follows:

1. the tests are organised under a source tree rooted at gnu/testlet.
2. a 'choose' script uses a KEYS variable to ultimately work out, which 
of the .java files, under java/ or javax/, are selected for processing; 
in the process it creates a 'classes' file that is fed to
3. SimpleTestHarness, when invoked by the 'make check' command.
4. to tailor the Mauve environment to the desired java bytecode 
compiler, bytecode interpreter or GCJ native code, the auto* machinery 
must be used --i.e. aclocal, automake, autoconf, configure.

to add new Mauve tests , one would select either the java/ or javax/ 
hierarchy and place the .java file there as:

a. belonging to package gnu.testlet.java[x].foo; and
b. adding a line that MUST start with '// Tags: ' to encode the level of 
compliance of that code with some standard; eg. JDK, JLS, JDBC, etc...
c. further refinement of what to [not] select can be done by adding 
special lines into a 'mauve-foo' text file that would be passed as 
'KEYS=foo' when 'make check'-ing.


I. GNU Crypto regression tests are all in packages with names that start 
with test.blah.  they mirror 1-for-1 gnu.crypto.blah packages.  
adopting a new name that starts with 'gnu.testlet.gnu.crypto' should 
not be a problem.

==> the 'choose' script has to be amended to look for .java files in a 
gnu/ directory, in addition to the current java/ and javax/ ones.  is 
this correct?


II. the 'choose' script seems to consider the value passed to KEYS; e.g. 
foo as a Tag to look for in the source files, _in addition_ to any 
other Tag that may be used in the '// Tags: ' line.  in other words, if 
in my 'mauve-gnu-crypto' file i have the following lines:

BAR
!gnu.crypto.cipher.BaseCipherTestCase

and in gnu/testlet/gnu/crypto/cipher i have a file, say TestOfSquare, 
that has the following line:

// Tags: gnu-crypto

it will get chosen by 'choose'.

if this is a guarranteed feature, then does it make sense to use the 
name of the PACKAGE; i.e. 'gnu-crypto' for these two tokens?


III. when i tried to use the exclusion mechanism --prefix the name of a 
class with ! after chopping off the gnu.testlet prefix-- the class, 
when it contains the '// Tags: xxx' line is always chosen.  is this a 
bug, or this mechanism is only intended for java[x] files?


IV. the mechanics of configuring Mauve, and GNU Crypto, are complicated; 
e.g. Mauve may not be installed on the user machine, if it is the user 
ends up dealing with 2 dissociate projects.  an easy alternative is to 
import the Mauve base classes and scripts into GNU Crypto, and handle 
the lot with the same toolchain.  the problem with this approach is 
that every time an enhancement is made to Mauve, the same has to be 
adopted for its twin in GNU Crypto.

is there a better way that we can use today?

are there any plans for releasing the Mauve framework (without any java/ 
javax/ etc.) on its own?


TIA + cheers;
rsn

cc: GNU Crypto discussion list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE99FrU+e1AKnsTRiERA6sXAJ95VBlqIfC6JQZjmvqgmsJ4XAcMYACePRi8
qbI5h/nFEURurBonYxCEVSU=
=r024
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]