* doc/ref.xml: Likewise.
(exit_remote_shell): Remove, as this procedure is defunct.
* doc/dejagnu.texi: Regenerate.
2011-12-30 Ben Elliston <bje@gnu.org>
+ * doc/user.xml: Various spelling and consistency fixes.
+ * doc/ref.xml: Likewise.
+ (exit_remote_shell): Remove, as this procedure is defunct.
+ * doc/dejagnu.texi: Regenerate.
+
+2011-12-30 Ben Elliston <bje@gnu.org>
+
* config.guess: Update to version 2011-12-29.
* config.sub: Update to version 2011-11-11.
@node A simple project without the GNU autotools, Using autoconf/autoheader/automake, , Create a minimal project; e_g_ calc
@subsection A simple project without the GNU autotools
-The runtest program can be run standalone. All the
+The runtest program can be run stand-alone. All the
autoconf/automake support is just cause those programs are commonly
-used for other GNU applications. The key to running runtest standalone
+used for other GNU applications. The key to running runtest stand-alone
is having the local site.exp file setup correctly, which automake
does.
Did you see the line "FAIL:"? The test cases for calc catch the bug in the calc.c file. Fix the error in calc.c later as the following examples assume a unchanged calc.c.
Examine the output files calc.sum and calc.log. Try to
-understand the testcases written in
+understand the test cases written in
~/dejagnu.test/testsuite/calc.test/calc.exp. To understand Expect you
might take a look at the book "Exploring Expect", which is
an excellent resource for learning and using Expect. (Pub: O'Reilly,
Calling runtest with the '--debug'-flag logs a lot of details to dbg.log where you can analyse it afterwards.
-In all test cases you can temporary adjust the verbosity of information by adding the following Tcl-command to any tcl file that gets loaded by
-dejagnu, for instance, ~/.dejagnurc:
+In all test cases you can temporary adjust the verbosity of
+information by adding the following Tcl command to any Tcl file that
+gets loaded by dejagnu, for instance, ~/.dejagnurc:
@example
Testing remote targets is a lot trickier especially if you are using an
embedded target
-which has no built in support for things like a compiler, ftp server or a Bash-shell.
+which has no built in support for things like a compiler, FTP server or a Bash-shell.
Before you can test calc on a remote target you have to acquire a few basics skills.
@menu
The easiest remote host is usually the host you are working on.
In this example we will use telnet to login in your own workstation.
For security reasons you should never have a telnet daemon running on
-machine connected on the internet, as password and usernames are transmitted
+machine connected on the Internet, as password and user names are transmitted
in clear text.
We assume you know how to setup your machine for a telnet daemon.
Now setup a real target.
In the following example we assume as target a PowerBook running Debian.
-As above add a test user "dgt", install telnet and FTP servers.
+As above add a test user "dgt", install Telnet and FTP servers.
In order to distinguish it from the host add the line
@example
``triple'' name as used by @code{configure}. This
is the type of machine DejaGnu and the tools to be tested are built
on. For a normal cross this is the same as the host, but for a
-canadian cross, they are separate.
+Canadian cross, they are separate.
@item @code{--host [string]}
@code{string} is a full configuration
be run on, which may not be the same as the
@emph{build} machine. If @code{--build}
is also specified, then @code{--host} refers to the
-machine that the tests wil, be run on, not the machine DejaGnu is run
+machine that the tests will be run on, not the machine DejaGnu is run
on.
@item @code{--host_board [name]}
target between multiple developers. There are settings for both
remote targets and remote hosts. Here's an example of a Master
Config File (also called the Global config file) for a
-@emph{canadian cross}. A canadian cross is when
+@emph{Canadian cross}. A Canadian cross is when
you build and test a cross compiler on a machine other than the
one it's to be hosted on.
don't support Expect, DejaGnu can be run on the local build
machine, and it can connect to the remote host and run all the
tests for this cross compiler on that host. All the remote OS
-requires is a working telnetd.
+requires is a working Telnet server.
As you can see, all one does is set the variable
@code{target_list} to the list of targets and options to
@strong{Note}
-Thanks to Dj Delorie for the original paper that
+Thanks to DJ Delorie for the original paper that
this section is based on.
@end quotation
DejaGnu also supports running the tests on a remote
-host. To set this up, the remote host needs an ftp server, and a
+host. To set this up, the remote host needs an FTP server, and a
telnet server. Currently foreign operating systems used as
remote hosts are VxWorks, VRTX, DOS/Windows 3.1, MacOS and Windows.
@section Config File Values
DejaGnu uses a named array in Tcl to hold all the info for
-each machine. In the case of a canadian cross, this means host
+each machine. In the case of a Canadian cross, this means host
information as well as target information. The named array is
called @code{target_info}, and it has two indices. The
following fields are part of the array.
DejaGnu uses a single header file to assist in unit
testing. As this file also produces its one test state output,
-it can be run standalone, which is very useful for testing on
+it can be run stand-alone, which is very useful for testing on
embedded systems. This header file has a C and C++ API for the
test states, with simple totals, and standardized
output. Because the output has been standardized, DejaGnu can be
@node Installing DejaGnu, , Configuring DejaGnu, Installation
@subsection Installing DejaGnu
-To install DejaGnu in your filesystem (either in
+To install DejaGnu in your file system (either in
@file{/usr/local}, or as specified by your
@code{--prefix} option to @emph{configure}),
execute.
@node is3way procedure, ishost procedure, is_remote procedure, Core Internal Procedures
@subsubsection is3way Procedure
-Tests for a canadian cross. This is when the tests will be run
-on a remotely hosted cross compiler. If it is a canadian cross, then
+Tests for a Canadian cross. This is when the tests will be run
+on a remotely hosted cross compiler. If it is a Canadian cross, then
the result is @emph{1}; otherwise the result is
@emph{0}.
@code{exec} as this version utilizes the target config
info to execute this command on the build machine or a remote
host. All config information for the remote host must be setup to
-have this command work. If this is a canadian cross, (where we test a
+have this command work. If this is a Canadian cross (where we test a
cross compiler that runs on a different host then where DejaGnu is
running) then a connection is made to the remote host and the command
is executed there. It returns either REMOTERROR (for an error) or the
<sect3 id="installing" xreflabel="Installing DejaGnu">
<title>Installing &dj;</title>
- <para>To install &dj; in your filesystem (either in
+ <para>To install &dj; in your file system (either in
<filename>/usr/local</filename>, or as specified by your
<option>--prefix</option> option to <emphasis>configure</emphasis>),
execute.</para>
<sect4 id="is3way" xreflabel="is3way procedure">
<title>is3way Procedure</title>
- <para>Tests for a canadian cross. This is when the tests will be run
- on a remotely hosted cross compiler. If it is a canadian cross, then
+ <para>Tests for a Canadian cross. This is when the tests will be run
+ on a remotely hosted cross compiler. If it is a Canadian cross, then
the result is <emphasis>1</emphasis>; otherwise the result is
<emphasis>0</emphasis>.</para>
</varlistentry>
</variablelist>
</sect4>
-
-<!-- FIXME: this doesn't seem to exist anymore
- <sect4 id="exitremoteshell" xreflabel="exit_remote_shell procedure">
- <title>exit_remote_shell Procedure</title>
-
- <para></para>
-
- <funcsynopsis role="tcl">
- <funcprototype>
- <funcdef><function>exit_remote_shell</function></funcdef>
- <paramdef><parameter>spawnid</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
- <variablelist>
- <varlistentry>
- <term><parameter>spawnid</parameter></term>
- <listitem><para>Exits a remote process started by any
- of the connection procedures. <symbol>spawnid</symbol>
- is the result of the connection procedure that started
- the remote process.</para></listitem>
- </varlistentry>
- </variablelist>
- </sect4>
--->
-
</sect3>
<sect3 id="connprocs" xreflabel="connprocs">
<command>exec</command> as this version utilizes the target config
info to execute this command on the build machine or a remote
host. All config information for the remote host must be setup to
- have this command work. If this is a canadian cross, (where we test a
+ have this command work. If this is a Canadian cross (where we test a
cross compiler that runs on a different host then where &dj; is
running) then a connection is made to the remote host and the command
is executed there. It returns either REMOTERROR (for an error) or the
sgml-local-ecat-files:nil
End:
-->
+
+<!-- LocalWords: spawnid
+ -->
<sect3><title>A simple project without the GNU autotools</title>
-<para>The runtest program can be run standalone. All the
+<para>The runtest program can be run stand-alone. All the
autoconf/automake support is just cause those programs are commonly
-used for other GNU applications. The key to running runtest standalone
+used for other GNU applications. The key to running runtest stand-alone
is having the local site.exp file setup correctly, which automake
does.</para>
<para>Did you see the line "FAIL:"? The test cases for calc catch the bug in the calc.c file. Fix the error in calc.c later as the following examples assume a unchanged calc.c.</para>
<para>Examine the output files calc.sum and calc.log. Try to
-understand the testcases written in
+understand the test cases written in
~/dejagnu.test/testsuite/calc.test/calc.exp. To understand Expect you
might take a look at the book "Exploring Expect", which is
an excellent resource for learning and using Expect. (Pub: O'Reilly,
<para>Calling runtest with the '--debug'-flag logs a lot of details to dbg.log where you can analyse it afterwards. </para>
-<para>In all test cases you can temporary adjust the verbosity of information by adding the following Tcl-command to any tcl file that gets loaded by
-dejagnu, for instance, ~/.dejagnurc:</para>
+<para>In all test cases you can temporary adjust the verbosity of
+information by adding the following Tcl command to any Tcl file that
+gets loaded by dejagnu, for instance, ~/.dejagnurc:</para>
<programlisting>
set verbose 9
<para>Testing remote targets is a lot trickier especially if you are using an
embedded target
-which has no built in support for things like a compiler, ftp server or a Bash-shell.
+which has no built in support for things like a compiler, FTP server or a Bash-shell.
Before you can test calc on a remote target you have to acquire a few basics skills.</para>
<sect3>
<para>The easiest remote host is usually the host you are working on.
In this example we will use telnet to login in your own workstation.
For security reasons you should never have a telnet daemon running on
-machine connected on the internet, as password and usernames are transmitted
+machine connected on the Internet, as password and user names are transmitted
in clear text.
We assume you know how to setup your machine for a telnet daemon.</para>
<para>Now setup a real target.
In the following example we assume as target a PowerBook running Debian.
-As above add a test user "dgt", install telnet and FTP servers.
+As above add a test user "dgt", install Telnet and FTP servers.
In order to distinguish it from the host add the line
<programlisting>PS1='test:>'</programlisting> to /home/dgt/.bash_profile.
Also add a corresponding entry "powerbook" to /etc/hosts and verify that you
``triple'' name as used by <command>configure</command>. This
is the type of machine &dj; and the tools to be tested are built
on. For a normal cross this is the same as the host, but for a
- canadian cross, they are separate.</para></listitem>
+ Canadian cross, they are separate.</para></listitem>
</varlistentry>
<varlistentry>
be run on, which may not be the same as the
<emphasis>build</emphasis> machine. If <option>--build</option>
is also specified, then <option>--host</option> refers to the
- machine that the tests wil, be run on, not the machine &dj; is run
+ machine that the tests will be run on, not the machine &dj; is run
on.</para></listitem>
</varlistentry>
target between multiple developers. There are settings for both
remote targets and remote hosts. Here's an example of a Master
Config File (also called the Global config file) for a
- <emphasis>canadian cross</emphasis>. A canadian cross is when
+ <emphasis>Canadian cross</emphasis>. A Canadian cross is when
you build and test a cross compiler on a machine other than the
one it's to be hosted on.</para>
don't support Expect, &dj; can be run on the local build
machine, and it can connect to the remote host and run all the
tests for this cross compiler on that host. All the remote OS
- requires is a working telnetd.</para>
+ requires is a working Telnet server.</para>
<para>As you can see, all one does is set the variable
<symbol>target_list</symbol> to the list of targets and options to
<sect2 id="releng" xreflabel="Remote Host Testing">
<title>Remote Host Testing</title>
- <note><para>Thanks to Dj Delorie for the original paper that
+ <note><para>Thanks to DJ Delorie for the original paper that
this section is based on.</para></note>
<para>&dj; also supports running the tests on a remote
- host. To set this up, the remote host needs an ftp server, and a
+ host. To set this up, the remote host needs an FTP server, and a
telnet server. Currently foreign operating systems used as
remote hosts are VxWorks, VRTX, DOS/Windows 3.1, MacOS and Windows.</para>
<title>Config File Values</title>
<para>&dj; uses a named array in Tcl to hold all the info for
- each machine. In the case of a canadian cross, this means host
+ each machine. In the case of a Canadian cross, this means host
information as well as target information. The named array is
called <symbol>target_info</symbol>, and it has two indices. The
following fields are part of the array.</para>
<para>&dj; uses a single header file to assist in unit
testing. As this file also produces its one test state output,
- it can be run standalone, which is very useful for testing on
+ it can be run stand-alone, which is very useful for testing on
embedded systems. This header file has a C and C++ API for the
test states, with simple totals, and standardized
output. Because the output has been standardized, &dj; can be
projects / platform / upstream / dejagnu.git / commitdiff