File: README

package info (click to toggle)
gnudatalanguage 0.9.5-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 15,228 kB
  • ctags: 11,455
  • sloc: cpp: 143,352; makefile: 426; sh: 103; ansic: 44; awk: 18; python: 6
file content (51 lines) | stat: -rw-r--r-- 2,016 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
The list of GDL routines to be executed during the make-check run is 
defined in the testsuite/Makefile.am file. After adding a new item 
(filename) to the list, please rerun "automake" being in the root 
folder of the source tree. CMake also uses the list in Makefile.am.

Each test routine is invoked using the GDL "-e" command-line option 
by the "try" shell script in the testsuite directory (and in an
analogous manner for the case of CMake/CTest). "make" decides
on the status of a test basing on the exit code of this script:
- "success" for exit code 0 
- "ignorable failure" for code 77
- "failure" for any other exit code, e.g. 1
The "try" script should, in principle, exit with the GDL exit code.
Therefore, a failure of a GDL test should be indicated by e.g.:

  if ( ...true if test failed... ) begin
    message, 'reason for the failure', /continue
    exit, status=1
  endif

An ignorable failure can be indicated by e.g.:

  if (!XXX_exists()) then begin
    message, 'GDL was built w/o support for XXX - skipping', /conti
    exit, status=77
  endif

Any GDL error (e.g. parser error or library-routine-triggered error)
causing GDL to return to the $MAIN$ level will cause make to assume 
_success_! (GDL exits normally in this case). Any GDL error causing
GDL to stop execution on an other-than-$MAIN$ level will bring the
GDL interpreter prompt.

The name of the file must match the name of the test routine, e.g.
testsuite/test_dummy.pro for
  
  pro test_dummy
    ...
  end

GDL segfaults, assertion-exits, std::terminate() exits, etc. are 
handled as failures by make.

The "try" script always uses the gdl binary in the build tree - 
not the one installed in the system. The "try" script also sets 
appropriate env. variables so that the GDL-written library routines 
are taken from the source tree as well (e.g. src/pro/mean.pro).

Regardless if the autotools or the CMake/CTest configuration 
mechanism, the testsuite run is invoked by "make check" (not the 
default CMakes's "make test").