Installing DejaGnu

Once you have the DejaGnu source unpacked and available, you must first configure the software to specify where it is to run (and the associated defaults); then you can proceed to installing it.

• Configuring DejaGnu
• Installing DejaGnu

Configuring the DejaGnu test driver

Configuring DejaGnu records information about the host (where runtest executes) and target (where the tools and their output are tested). It is usually best to configure in a directory separate from the source tree, specifying where to find the source with the `--srcdir' option to configure:

configure host-type --target=target-type --srcdir=path

To run tests on a full-fledged operating system, you can specify host and target as the same machine; we call this a native configuration. For native configurations, specifying the target explicitly is not necessary. For example, to configure for a Sun-4 running SunOS:

configure sun4 --srcdir=/usr/cygnus/src/dejagnu

When the host and target are not the same (typically when testing software tools on a "bare board" controlled from a separate general-purpose computer), we refer to a cross configuration. For example, to run tests controlled by Sun-4 on an AMD 29000 board, communicating via the AMD "UDI" protocol:

configure sun4 --target=a29k-amd-udi \
    --srcdir=/usr/cygnus/src/dejagnu

You may also want to use the configure option `--prefix' to specify where you want DejaGnu and its supporting code installed. By default, installation is in subdirectories of `/usr/local', but you can select any alternate directory altdir by including `--prefix=altdir' on the configure command line. (This value is captured in the Makefile variables prefix and exec_prefix.)

DejaGnu uses Cygnus Configure. See section `What Configure Does' in Cygnus Configure, for more information on its capabilities, conventions, and command-line options.

Aside from the usual effect of preparing and building the executables on your host, configuring and making DejaGnu creates a file called `site.exp'. This file encapsulates information from both configure and make, as default values for DejaGnu tests. See section Setting runtest defaults.

Save for a small number of example tests, the DejaGnu distribution itself does not include any test suites; these are available separately. Test suites for the GNU compiler (testing both GCC and G++) and for the GNU binary utilities are distributed in parallel with the DejaGnu distribution (but packaged as separate files). The test suite for the GNU debugger is distributed in parallel with each release of GDB itself, starting with GDB 4.9. After configuring the top-level DejaGnu directory, unpack and configure the test directories for the tools you want to test; then, in each test directory, run make to build auxiliary programs required by some of the tests.

Installing DejaGnu

To install DejaGnu in your filesystem (either in `/usr/local', or as specified by your `--prefix' option to configure), execute

eg$ make install

`make install' does these things for DejaGnu:

1. Look in the path specified for executables (`$exec_prefix') for directories called `lib' and `bin'. If these directories do not exist, `make install' creates them.
2. Create another directory in the `lib' directory, called `dejagnu'.
3. Create a subdirectory of `lib/dejagnu' whose name is the target configuration string. For a native configuration, `make install' creates two configuration-specific directories: one with the usual configuration name, and another called `native'.
4. Copy the runtest shell script into `$exec_prefix/bin'.
5. Copy all the library files (used to support the framework) into `$exec_prefix/lib/dejagnu'.
6. Copy `runtest.exp' into `$exec_prefix/lib/dejagnu'. This is the main Tcl code implementing DejaGnu.
7. Copy the `site.tmpl' file (which captures configuration values in Tcl variables) into a the directory `$exec_prefix/lib/dejagnu/'. `site.tmpl' is a template of a working config file. The installation process edits it into `site.exp'. Each site where DejaGnu is installed should edit the values in this file to reflect local practice.

Each test suite collection comes with simple installation instructions in a `README' file; in general, the test suites are designed to be unpacked in the source directory for the corresponding tool, and extract into a directory called `testsuite'.