This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
request for comments (long)
- From: "Raif S. Naffah" <raif at fl dot net dot au>(by way of Raif S. Naffah <raif at fl dot net dot au>)
- To: Mauve <mauve-discuss at sources dot redhat dot com>
- Cc: GNU Crypto <gnu-crypto-discuss at gnu dot org>
- Date: Tue, 10 Dec 2002 05:30:03 +1100
- Subject: request for comments (long)
- Reply-to: raif at fl dot net dot au
-----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 files 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' 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=/tmp/uses-$$
: > $usesfile
- -(cd gnu/testlet; find java javax -name '*.java' -print) |
+(cd gnu/testlet; find java javax gnu -name '*.java' -print) |
while read file; do
exact_match=no
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:
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
$(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 Makefile.am there as follows:
Index: Makefile.am
===================================================================
RCS file: /cvs/mauve/mauve/Makefile.am,v
retrieving revision 1.22
diff -u -r1.22 Makefile.am
- --- Makefile.am 13 Jun 2002 17:11:28 -0000 1.22
+++ Makefile.am 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/config.java $(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 Makefile.am add something like:
# Mauve targets
---------------------------------------------------------------
if FOUND_MAUVE_DIR
KEYS=$(PACKAGE)
TESTFLAGS="-verbose -debug"
configure-mauve:
cd @MAUVE_DIR@ ; aclocal ; automake ; autoconf
cd @MAUVE_DIR@ ; GCJFLAGS="$(GCJFLAGS) --classpath .:@SRCDIR@/source"
./configure --with-gcj
run-mauve:
rm -f @MAUVE_DIR@/.save-keys choices
LD_LIBRARY_PATH=$$LD_LIBRARY_PATH$(PATH_SEPARATOR)@SRCDIR@/source/.lib
s \ $(MAKE) -C @MAUVE_DIR@ check
package_so="@SRCDIR@/source/.libs/lib-gnu-crypto.so" AM_GCJFLAGS="-I.
-I@SRCDIR@/source" KEYS=$(KEYS) TESTFLAGS=$(TESTFLAGS)
endif # FOUND_MAUVE_DIR
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;
rsn
cc: GNU Crypto discussion list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique
iD8DBQE99N/e+e1AKnsTRiERA5AfAJsFB62kLqzFr4o499RTKIrls/xx9gCfa1l8
AiEO41auVCKBFLpHZXiv//s=
=h/SA
-----END PGP SIGNATURE-----