This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

request for comments (long)

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 files there as:

a. belonging to package[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' spec 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.  i.e.

Index: choose
RCS file: /cvs/mauve/mauve/choose,v
retrieving revision 1.21
diff -u -r1.21 choose
- --- choose	12 Jul 2002 19:33:27 -0000	1.21
+++ choose	9 Dec 2002 17:57:12 -0000
@@ -61,7 +61,8 @@
        echo "Invalid tag: $i" 1>&2
        exit 1
- -    !java.* | java.* | !javax.* | javax.*)
+#    !java.* | java.* | !javax.* | javax.*)
+    !java.* | java.* | !javax.* | javax.* | !gnu.* | gnu.*)
        file="`echo $i | tr . /`"
        file_specs="$file_specs $file"
@@ -130,7 +131,7 @@

 : > $usesfile

- -(cd gnu/testlet; find java javax -name '*.java' -print) |
+(cd gnu/testlet; find java javax gnu -name '*.java' -print) |
 while read file; do
    test -n "$verbose" && echo "Examining $file"

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:


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

the 'choose' script has to be amended (see above diff).

IV. the mechanics of configuring Mauve, and GNU Crypto, are
 complicated; the easy approach is to (a) add the gnu/crypto/ test
 classes under gnu/testlet, (b) have the user checkout both GNU Crypto
 and Mauve, (c) amend there as follows:

RCS file: /cvs/mauve/mauve/,v
retrieving revision 1.22
diff -u -r1.22
- ---	13 Jun 2002 17:11:28 -0000	1.22
+++	9 Dec 2002 18:04:00 -0000
@@ -66,10 +66,12 @@
 check_PROGRAMS = SimpleTestHarness

 AM_GCJFLAGS = -I. -I$(srcdir)
+package_so =

 SimpleTestHarness_SOURCES = gnu/testlet/ $(harness_files)
- -SimpleTestHarness_DEPENDENCIES = $(STAMP) $(javao_files)
- -SimpleTestHarness_LDADD = $(javao_files)
+SimpleTestHarness_DEPENDENCIES = $(STAMP) $(javao_files)
+#SimpleTestHarness_LDADD = $(javao_files)
+SimpleTestHarness_LDADD = $(javao_files) $(package_so)
 SimpleTestHarness_LDFLAGS = --main=gnu.testlet.SimpleTestHarness

 check-local: $(check_PROGRAMS) $(CHOICES)

and (d) in GNU Crypto add something like:

# Mauve targets


TESTFLAGS="-verbose -debug"

	cd @MAUVE_DIR@ ; aclocal ; automake ; autoconf
	cd @MAUVE_DIR@ ; GCJFLAGS="$(GCJFLAGS) --classpath .:@SRCDIR@/source"
 ./configure --with-gcj

	rm -f @MAUVE_DIR@/.save-keys choices
s \ $(MAKE) -C @MAUVE_DIR@ check
 package_so="@SRCDIR@/source/.libs/" AM_GCJFLAGS="-I.


the problem with this approach is that the test sources are in a
different tree than the project.

another approach 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?

TIA + cheers;

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]