From: Wolfgang Bangerth Date: Thu, 8 Dec 2005 03:11:10 +0000 (+0000) Subject: Reword a few things. X-Git-Tag: v8.0.0~12798 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=efdf87fb325f8b6114d4f4c5a1d1c8f82a6ef1a8;p=dealii.git Reword a few things. git-svn-id: https://svn.dealii.org/trunk@11838 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/development/testsuite.html b/deal.II/doc/development/testsuite.html index 32c7a69e93..7f87576b5d 100644 --- a/deal.II/doc/development/testsuite.html +++ b/deal.II/doc/development/testsuite.html @@ -18,9 +18,9 @@

The deal.II testsuite consists of two parts, the build tests and the regression tests. While the build tests just check if the - library can be compiled on different systems, the regression tests - actually are actually run and compare the output of the testy - programs with precomputed values. These two testsuites are + library can be compiled on different systems and with different (versions + of) compilers, the regression tests are actually run and their output + compared with previously stored. These two testsuites are described below.

The build tests

@@ -35,7 +35,9 @@ users with configurations not found on the build test page to participate. Assuming you checked out deal.II into the directory - dealtest, running it is as simple as:

+ dealtest, running it is as simple as (you may want to pass + different options than the ones given as BUILDTESTFLAGS to + ./configure):

 
@@ -51,19 +53,24 @@
     most recent version, the make command configures the
     library (here for use of UMFPack and LAPACK libraries) and
     compiles everything. The result is in the file
-    build-test-log, Which is sent to the build test demon
-    in the end.

+ build-test-log, which is sent to the build test demon + in the end. A status indicator should appear on the build test website + after some time (results are collected and processed by a program that is + run periodically, but not immediately after a mail has been received). +

Configuring for a special compiler

If your compiler is not in the standard path or has a strange name (like mycc for C and myCC for C++), - your template would be something like this:

+ your template would be something like this (assuming you work with the + bash shell):

 
     export PATH=/my/compiler/path:$PATH
-    
+    export CXX=myCC
+
     cd dealtest
     make clean
     cvs update -d -P
@@ -71,10 +78,43 @@
     mail build-tests@dealii.org < build-test-log
 
     
+ + +

Dedicated tests

+ +

+ Most of our tests are built in dedicated directories, i.e. work on copies + of deal.II that we don't usually use to work on every day. We do this, + because we want to see if the version in the CVS repository can be + compiled, not the version that we have made changes in. +

+ +

+ In this case, one would check out a new version, and do essentially the + same things as above: + +

+
+    export PATH=/my/compiler/path:$PATH
+    export CXX=myCC
+
+    cvs checkout deal.II
+    cd deal.II
+    cvs update -d -P
+    make build-test BUILDTEST=yes BUILDTESTFLAGS='CC=mycc CXX=myCC'
+    mail build-tests@dealii.org < build-test-log
+    cd ..
+    rm -rf deal.II
+
+    
- If the directory has never been configured before calling - make build-test, then the option - BUILDTEST=yes must be added. + The only difference is that one has to give the option + BUILDTEST=yes to the call to make. This is so + because for the make file to work it depends on a file that is created by + ./configure; the latter, however, hasn't run on this pristine + copy yet. +

+

The regression tests