第1页 / 共110页
第2页 / 共110页
第3页 / 共110页
第4页 / 共110页
第5页 / 共110页
第6页 / 共110页
第7页 / 共110页
第8页 / 共110页
dejagnu,pdf.pdf
1. Abstract
2. Overview
2.1. What is DejaGnu ?
2.2. New In This Release
2.2.1. Windows Support
2.3. Design Goals
2.4. A POSIX conforming test framework
3. Getting DejaGnu up and running
3.1. Test your installation
3.1.1. Windows
3.1.2. Getting the source code for the calc example
3.2. Create a minimal project, e.g. calc
3.2.1. A simple project without the GNU autotools
3.2.2. Using autoconf/autoheader/automake
3.3. Our first automated tests
3.3.1. Running the test for the calc example
3.3.2. The various config files or how to avoid warnings
3.3.3. When trouble strikes
3.3.4. Testing "Hello world" locally
3.4. A first remote test
3.4.1. Setup telnet to your own host
3.4.2. A test case for login via telnet
3.4.3. Remote testing "Hello world"
3.4.4. Transferring files from/to the target
3.4.5. Preparing for crosscompilation
3.4.6. Remote testing of calc
3.4.7. Using Windows as host and vxWorks as target
4. Running Tests
4.1. Make check
4.2. Runtest
4.2.1. Output States
4.2.2. Invoking Runtest
4.2.3. Common Options
4.3. The files DejaGnu produces.
4.3.1. Summary File
4.3.2. Log File
4.3.3. Debug Log File
5. Customizing DejaGnu
5.1. Local Config File
5.2. Global Config File
5.3. Board Config File
5.4. Remote Host Testing
5.5. Config File Values
5.5.1. Command Line Option Variables
5.5.2. Personal Config File
6. Extending DejaGnu
6.1. Adding A New Testsuite
6.2. Adding A New Tool
6.3. Adding A New Target
6.4. Adding A New Board
6.5. Board Config File Values
6.6. Writing A Test Case
6.7. Debugging A Test Case
6.8. Adding A Test Case To A Testsuite.
6.9. Hints On Writing A Test Case
6.10. Special variables used by test cases.
7. Unit Testing
7.1. What Is Unit Testing ?
7.2. The dejagnu.h Header File
8. Reference
8.1. Obtaining DejaGnu
8.2. Installation
8.2.1. Configuring DejaGnu
8.2.2. Installing DejaGnu
8.3. Builtin Procedures
8.3.1. Core Internal Procedures
8.3.1.1. Mailfile Procedure
8.3.1.2. Openlogs Procedure
8.3.1.3. Closelogs Procedure
8.3.1.4. Isbuild Procedure
8.3.1.5. Isremote Procedure
8.3.1.6. is3way Procedure
8.3.1.7. Ishost Procedure
8.3.1.8. Istarget Procedure
8.3.1.9. Isnative Procedure
8.3.1.10. Unknown Procedure
8.3.1.11. Cloneoutput Procedure
8.3.1.12. Resetvars Procedure
8.3.1.13. Logandexit Procedure
8.3.1.14. Logsummary Procedure
8.3.1.15. Cleanup Procedure
8.3.1.16. Setupxfail Procedure
8.3.1.17. Recordtest Procedure
8.3.1.18. Pass Procedure
8.3.1.19. Fail Procedure
8.3.1.20. Xpass Procedure
8.3.1.21. Xfail Procedure
8.3.1.22. Setwarningthreshold Procedure
8.3.1.23. Getwarningthreshold Procedure
8.3.1.24. Warning Procedure
8.3.1.25. Perror Procedure
8.3.1.26. Note Procedure
8.3.1.27. Untested Procedure
8.3.1.28. Unresolved Procedure
8.3.1.29. Unsupported Procedure
8.3.1.30. Inittestcounts Procedure
8.3.1.31. Incrcount Procedure
8.3.1.32. transform Procedure
8.3.1.33. Checkconditionalxfail Procedure
8.3.1.34. Clearxfail Procedure
8.3.1.35. Verbose Procedure
8.3.1.36. Loadlib Procedure
8.3.2. Procedures For Remote Communication
8.3.2.1. Callremote Procedure
8.3.2.2. Checkforboardstatus Procedure
8.3.2.3. Fileonbuild Procedure
8.3.2.4. Fileonhost Procedure
8.3.2.5. Localexec Procedure
8.3.2.6. Remotebinary Procedure
8.3.2.7. Remoteclose Procedure
8.3.2.8. Remotedownload Procedure
8.3.2.9. Remoteexec Procedure
8.3.2.10. Remoteexpect Procedure
8.3.2.11. Remotefile Procedure
8.3.2.12. Remoteld Procedure
8.3.2.13. Remoteload Procedure
8.3.2.14. Remoteopen Procedure
8.3.2.15. Remotepopconn Procedure
8.3.2.16. Remotepushconn Procedure
8.3.2.17. Remoterawbinary Procedure
8.3.2.18. Remoterawclose Procedure
8.3.2.19. Remoterawfile Procedure
8.3.2.20. remoterawld Procedure
8.3.2.21. Remoterawload Procedure
8.3.2.22. Remoterawopen Procedure
8.3.2.23. Remoterawsend Procedure
8.3.2.24. Remoterawspawn Procedure
8.3.2.25. Remoterawtransmit Procedure
8.3.2.26. Remoterawwait Procedure
8.3.2.27. Remotereboot Procedure
8.3.2.28. Remotesend Procedure
8.3.2.29. Remotespawn Procedure
8.3.2.30. Remoteswapconn Procedure
8.3.2.31. Remotetransmit Procedure
8.3.2.32. Remoteupload Procedure
8.3.2.33. Remotewait Procedure
8.3.2.34. Standardclose Procedure
8.3.2.35. Standarddownload Procedure
8.3.2.36. Standardexec Procedure
8.3.2.37. Standardfile Procedure
8.3.2.38. Standardload Procedure
8.3.2.39. Standardreboot Procedure
8.3.2.40. Standardsend Procedure
8.3.2.41. Standardspawn Procedure
8.3.2.42. Standardtransmit Procedure
8.3.2.43. Standardupload Procedure
8.3.2.44. Standardwait Procedure
8.3.2.45. Unixcleanfilename Procedure
8.3.3. Procedures For Using Utilities to Connect
8.3.3.1. telnet Procedure
8.3.3.2. rsh Procedure
8.3.3.3. Tip Procedure
8.3.3.4. Kermit Procedure
8.3.3.5. kermitopen Procedure
8.3.3.6. Kermitcommand Procedure
8.3.3.7. Kermitsend Procedure
8.3.3.8. Kermittransmit Procedure
8.3.3.9. Telnetopen Procedure
8.3.3.10. Telnetbinary Procedure
8.3.3.11. Telnettransmit Procedure
8.3.3.12. Tipopen Procedure
8.3.3.13. Rloginopen Procedure
8.3.3.14. Rloginspawn Procedure
8.3.3.15. Rshopen Procedure
8.3.3.16. Rshdownload Procedure
8.3.3.17. Rshupload Procedure
8.3.3.18. Rshexec Procedure
8.3.3.19. Ftpopen Procedure
8.3.3.20. Ftpupload Procedure
8.3.3.21. Ftpdownload Procedure
8.3.3.22. Ftpclose Procedure
8.3.3.23. Tipdownload Procedure
8.3.4. Procedures For Target Boards
8.3.4.1. Defaultlink Procedure
8.3.4.2. Defaulttargetassemble Procedure
8.3.4.3. defaulttargetcompile Procedure
8.3.4.4. Popconfig Procedure
8.3.4.5. Prunewarnings Procedure
8.3.4.6. Pushbuild Procedure
8.3.4.7. pushconfig Procedure
8.3.4.8. Reboottarget Procedure
8.3.4.9. Targetassemble Procedure
8.3.4.10. Targetcompile Procedure
8.3.5. Target Database Procedures
8.3.5.1. Boardinfo Procedure
8.3.5.2. Hostinfo Procedure
8.3.5.3. Setboardinfo Procedure
8.3.5.4. Setcurrtargetinfo Procedure
8.3.5.5. Targetinfo Procedure
8.3.5.6. Unsetboardinfo Procedure
8.3.5.7. Unsetcurrtargetinfo Procedure
8.3.5.8. Pushtarget Procedure
8.3.5.9. Poptarget Procedure
8.3.5.10. Listtargets Procedure
8.3.5.11. Pushhost Procedure
8.3.5.12. Pophost Procedure
8.3.5.13. Compile Procedure
8.3.5.14. Archive Procedure
8.3.5.15. Ranlib Procedure
8.3.5.16. Executeanywhere Procedure
8.3.6. Platform Dependent Procedures
8.3.6.1. tool_start Procedure
8.3.6.2. tool_load Procedure
8.3.6.3. tool_exit Procedure
8.3.6.4. tool_version Procedure
8.3.7. Utility Procedures
8.3.7.1. Getdirs Procedure
8.3.7.2. Find Procedure
8.3.7.3. Which Procedure
8.3.7.4. Grep Procedure
8.3.7.5. Prune Procedure
8.3.7.6. Slay Procedure
8.3.7.7. Absolute Procedure
8.3.7.8. Psource Procedure
8.3.7.9. Runtestfilep Procedure
8.3.7.10. Diff Procedure
8.3.7.11. Setenv Procedure
8.3.7.12. unsetenv Procedure
8.3.7.13. Getenv Procedure
8.3.7.14. Prunesystemcrud Procedure
8.3.8. Libgloss, A Free BSP
8.3.8.1. Libglosslinkflags Procedure
8.3.8.2. Libglossincludeflags Procedure
8.3.8.3. Newliblinkflags Procedure
8.3.8.4. Newlibincludeflags Procedure
8.3.8.5. Libioincludeflags Procedure
8.3.8.6. Libiolinkflags Procedure
8.3.8.7. G++includeflags Procedure
8.3.8.8. G++linkflags Procedure
8.3.8.9. Libstdc++includeflags Procedure
8.3.8.10. Libstdc++linkflags Procedure
8.3.8.11. Getmultilibs Procedure
8.3.8.12. Findbinutilsprog Procedure
8.3.8.13. Findgcc Procedure
8.3.8.14. Findgcj Procedure
8.3.8.15. Findg++ Procedure
8.3.8.16. Findg77 Procedure
8.3.8.17. Processmultiliboptions Procedure
8.3.8.18. Addmultiliboption Procedure
8.3.8.19. Findgas Procedure
8.3.8.20. Findld Procedure
8.3.8.21. Buildwrapper Procedure
8.3.8.22. Winsupincludeflags Procedure
8.3.8.23. Winsuplinkflags Procedure
8.3.9. Procedures for debugging your Tcl code.
8.3.9.1. Dumpvars Procedure
8.3.9.2. Dumplocals Procedure
8.3.9.3. Dumprocs Procedure
8.3.9.4. Dumpwatch Procedure
8.3.9.5. Watcharray Procedure
8.3.9.6. Watchvar Procedure
8.3.9.7. Watchunset Procedure
8.3.9.8. Watchwrite Procedure
8.3.9.9. Watchread Procedure
8.3.9.10. Watchdel Procedure
8.3.9.11. Print Procedure
8.3.9.12. Quit Procedure
8.4. File Map
9. Unit Testing API
9.1. C Unit Testing API
9.1.1. Pass Function
9.1.2. Fail Function
9.1.3. Untested Function
9.1.4. Unresolved Function
9.1.5. Totals Function
9.2. C++ Unit Testing API
9.2.1. Pass Method
9.2.2. Fail Method
9.2.3. Untested Method
9.2.4. Unresolved Method
9.2.5. Totals Method
DejaGnu
The GNU Testing Framework
Rob Savoye
Ben Elliston
Copyright © 2006 Free Software Foundation, Inc.
Revision History
Revision 0.6.2 2002-07-16 Revised by: rob
Add new tutorial as a new sect1.
Revision 0.6.1 2001-02-16 Revised by: rob
Add info on the new dejagnu.h file.
Revision 0.6 2001-02-16 Revised by: rob
Updated for new release.
Revision 0.5 2000-01-24 Revised by: rob
Initial version after conversion to DocBook.
1. Abstract
This document describes the functionality of DejaGnu, the testing framework of the GNU project.
DejaGnu is written in Expect, which uses Tcl as a command language. Expect acts as a very
programmable shell. As with other Unix command shells, you can run any program, but once the
program is started, your test script has programmable control over its input and output. This does not just
apply to the programs under test; expect can also run any auxiliary program, such as diff or sh, with full
control over its input and output.
DejaGnu itself is merely a framework for the creation of testsuites. Testsuites are distributed with each
application.
2. Overview
2.1. What is DejaGnu ?
DejaGnu is a framework for testing other programs. Its purpose is to provide a single front end for all
tests. Think of it as a custom library of Tcl procedures crafted to support writing a test harness. A Test
Harness is the testing infrastructure that is created to support a specific program or tool. Each program
can have multiple testsuites, all supported by a single test harness. DejaGnu is written in Expect, which
1
DejaGnu
in turn uses Tcl -- Tool command language. There is more information on Tcl at the Scriptics
(http://www.scriptics.com) web site and the Expect web site is at NIST (http://expect.nist.gov).
Julia Menapace first coined the term “DejaGnu” to describe an earlier testing framework at Cygnus
Support she had written for GDB. When we replaced it with the Expect-based framework, it was like
DejaGnu all over again. More importantly, it was also named after my daughter, Deja Snow Savoye
(http://www.welcomehome.org/deja/) (now 14 years old as of Feb 2004), who was a toddler during
DejaGnu’s beginnings.
DejaGnu offers several advantages for testing:
• The flexibility and consistency of the DejaGnu framework make it easy to write tests for any program,
with either batch oriented, or interactive programs.
• DejaGnu provides a layer of abstraction which allows you to write tests that are portable to any host or
target where a program must be tested. For instance, a test for GDB can run from any supported host
system on any supported target system. DejaGnu runs tests on many single board computers, whose
operating software ranges from a simple boot monitor to a real-time OS.
• All tests have the same output format. This makes it easy to integrate testing into other software
development processes. DejaGnu’s output is designed to be parsed by other filtering script and it is
also human readable.
• Using Tcl and Expect, it’s easy to create wrappers for existing testsuites. By incorporating existing
tests under DejaGnu, it’s easier to have a single set of report analyse programs..
Running tests requires two things: the testing framework and the testsuites themselves. Tests are usually
written in Expect using Tcl, but you can also use a Tcl script to run a testsuite that is not based on
Expect. Expect script filenames conventionally use .exp as a suffix; for example, the main
implementation of the DejaGnu test driver is in the file runtest.exp.)
2.2. New In This Release
This release has a number of substantial changes over version 1.3. The most visible change is that the
version of Expect and Tcl included in the release are up-to-date with the current stable net releases. The
biggest change is years of modifications to the target configuration system, used for cross testing. While
this greatly improved cross testing, it has made that subsystem very complicated. The goal is to have this
entirely rewritten using iTcl by the next release. Other changes are:
• More built-in support for building target binaries with the correct linker flags. Currently this only
works with GCC as the cross compiler, preferably with a target supported by Libgloss.
• Lots of little bug fixes from years of heavy use at Cygnus Solutions.
• DejaGnu now uses Automake for Makefile configuration.
• Updated documentation, now in DocBook XML.
• Windows support. There is beta level support for Windows that is still a work in progress. This
requires the Cygwin (http://www.cygwin.com/) POSIX subsystem for Windows.
2
DejaGnu
2.2.1. Windows Support
To use DejaGnu on Windows, you need to first install the Cygwin (http://www.cygwin.com/) release.
This works as of the B20.1 release. Cygwin is a POSIX system for Windows. This covers both utility
programs and a library that adds POSIX system calls to Windows. Among them is pseudo tty support for
Windows that emulates the POSIX pty standard. The latest Cygwin is always available from this location
(http://www.cygwin.com/). This works well enough to run "make check" of the GNU development tree
on Windows after a native build. But the nature of ptys on Windows is still evolving. Your mileage may
vary.
2.3. Design Goals
DejaGnu grew out of the internal needs of Cygnus Solutions, the company formerly known as Cygnus
Support. Cygnus maintained and enhanced a variety of free programs in many different environments
and we needed a testing tool that:
• was useful to developers while fixing bugs;
• automated running many tests during a software release process;
• was portable among a variety of host computers;
• supported cross-development testing;
• permitted testing interactive programs, like GDB; and
• permitted testing batch oriented programs, like GCC.
Some of the requirements proved challenging. For example, interactive programs do not lend themselves
very well to automated testing. But all the requirements are important: for instance, it is imperative to
make sure that GDB works as well when cross-debugging as it does in a native configuration.
Probably the greatest challenge was testing in a cross-development environment. Most
cross-development environments are customized by each developer. Even when buying packaged boards
from vendors there are many differences. The communication interfaces vary from a serial line to
Ethernet. DejaGnu was designed with a modular communication setup, so that each kind of
communication can be added as required and supported thereafter. Once a communication procedure is
coded, any test can use it. Currently DejaGnu can use rsh, rlogin, telnet, tip, kermit and mondfe for
remote communications.
2.4. A POSIX conforming test framework
DejaGnu conforms to the POSIX 1003.3 standard for test frameworks. Rob Savoye was a member of that
committee.
3
DejaGnu
The POSIX standard 1003.3 defines what a testing framework needs to provide, in order to permit the
creation of POSIX conformance test suites. This standard is primarily oriented to running POSIX
conformance tests, but its requirements also support testing of features not related to POSIX
conformance. POSIX 1003.3 does not specify a particular testing framework, but at this time there is
only one other POSIX conforming test framework: TET. TET was created by Unisoft for a consortium
comprised of X/Open, Unix International and the Open Software Foundation.
The POSIX documentation refers to assertions. An assertion is a description of behavior. For example, if
a standard says “The sun shall shine”, a corresponding assertion might be “The sun is shining.” A test
based on this assertion would pass or fail depending on whether it is day or night. It is important to note
that the standard being tested is never 1003.3; the standard being tested is some other standard, for which
the assertions were written.
As there is no testsuite to test testing frameworks for POSIX 1003.3 conformance, verifying
conformance to this standard is done by repeatedly reading the standard and experimenting. One of the
main things 1003.3 does specify is the set of allowed output messages and their definitions. Four
messages are supported for a required feature of POSIX conforming systems and a fifth for a conditional
feature. DejaGnu supports the use of all five output messages. In this sense a testsuite that uses exactly
these messages can be considered POSIX conforming. These definitions specify the output of a test case:
PASS
A test has succeeded. That is, it demonstrated that the assertion is true.
XFAIL
POSIX 1003.3 does not incorporate the notion of expected failures, so PASS, instead of XPASS,
must also be returned for test cases which were expected to fail and did not. This means that PASS is
in some sense more ambiguous than if XPASS is also used.
FAIL
A test has produced the bug it was intended to capture. That is, it has demonstrated that the
assertion is false. The FAIL message is based on the test case only. Other messages are used to
indicate a failure of the framework. As with PASS, POSIX tests must return FAIL rather than XFAIL
even if a failure was expected.
UNRESOLVED
A test produced indeterminate results. Usually, this means the test executed in an unexpected
fashion; this outcome requires that a human being go over results, to determine if the test should
have passed or failed. This message is also used for any test that requires human intervention
because it is beyond the abilities of the testing framework. Any unresolved test should resolved to
PASS or FAIL before a test run can be considered finished.
Note that for POSIX, each assertion must produce a test result code. If the test isn’t actually run, it
must produce UNRESOLVED rather than just leaving that test out of the output. This means that you
have to be careful when writing tests to not carelessly use Tcl commands like return---if you alter
the flow of control of the Tcl code you must insure that every test still produces some result code.
4
Here are some of the ways a test may wind up UNRESOLVED:
DejaGnu
• A test’s execution is interrupted.
• A test does not produce a clear result. This is usually because there was an ERROR from DejaGnu
while processing the test, or because there were three or more WARNING messages. Any WARNING
or ERROR messages can invalidate the output of the test. This usually requires a human being to
examine the output to determine what really happened---and to improve the test case.
• A test depends on a previous test, which fails.
• The test was set up incorrectly.
UNTESTED
A test was not run. This is a place-holder, used when there is no real test case yet.
The only remaining output message left is intended to test features that are specified by the applicable
POSIX standard as conditional:
UNSUPPORTED
There is no support for the tested case. This may mean that a conditional feature of an operating
system, or of a compiler, is not implemented. DejaGnu also uses this message when a testing
environment (often a “bare board” target) lacks basic support for compiling or running the test case.
For example, a test for the system subroutine gethostname would never work on a target board
running only a boot monitor.
DejaGnu uses the same output procedures to produce these messages for all testsuites and these
procedures are already known to conform to POSIX 1003.3. For a DejaGnu testsuite to conform to
POSIX 1003.3, you must avoid the setupxfail} procedure as described in the PASS section above and you
must be careful to return UNRESOLVED where appropriate, as described in the UNRESOLVED section
above.
3. Getting DejaGnu up and running
This chapter was originally written by Niklaus Giger (ngiger@mus.ch) because he lost a week to figure
out how DejaGnu works and how to write a first test.
Follow these instructions as closely a possible in order get a good insight into how DejaGnu works, else
you might run into a lot of subtle problems. You have been warned.
It should be no big problems installing DejaGnu using your package manager or from the source code.
Under a Debian/GNU/Linux systems just type (as root)
5
DejaGnu
apt-get install
dejagnu
. These examples were run on a primary machine with a AMD K6 and a Mac Powerbook G3 serving as a
remote target.
The tests for Windows were run under Windows using the actual Cygwin version (1.3.x as of October
2001). Its target system was a PPC embedded system running vxWorks.
3.1. Test your installation
Create a new user called "dgt" (DejaGnuTest), which uses bash as it login shell. PS1 must be set to
’\u:\w\$ ’ in its ~/.bashrc. Login as this user, create an empty directory and change the working directory
to it. e.g
dgt:~$ mkdir ~/dejagnu.test
dgt:~$ cd ~/dejagnu.test
Now you are ready to test DejaGnu’s main program called runtest. The expected output is shown
Example 1. Runtest output in a empty directory
dgt:~/dejagnu.test$ runtest
WARNING: Couldn’t find the global config file.
WARNING: No tool specified Test
Run By dgt on Sun Nov 25 17:07:03 2001 Native configuration is i586-pc-linux-gnu
=== tests ===
Schedule of variations: unix
Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
ERROR: Couldn’t find tool config file for unix.
=== Summary ===
We will show you later how to get rid of all the WARNING- and ERROR-messages. The files
testrun.sum and testrun.log have been created, which do not interest us at this point. Let’s remove them.
:~/dejagnu.test$ rm testrun.sum testrun.log
3.1.1. Windows
On Windows systems DejaGnu is part of a port of a lot of Unix tools to the Windows OS, called Cygwin.
Cygwin may be downloaded and installed from a mirror of http://www.cygwin.com/. All examples were
also run on Windows. If nothing is said, you can assume that you should get the same output as on a
Unix system.
6
You will need a telnet daemon if you want to use a Windows box as a remote target. There seems to be a
freeware telnet daemon at http://www.fictional.net/.
DejaGnu
3.1.2. Getting the source code for the calc example
If you are running a Debian distribution you can find the examples under
/usr/share/doc/dejagnu/examples. These examples seem to be missing in Red Hat’s RPM. In this case
download the sources of DejaGnu and adjust the paths to the DejaGnu examples accordingly.
3.2. Create a minimal project, e.g. calc
In this section you will to start a small project, using the sample application calc, which is part of your
DejaGnu distribution
3.2.1. A simple project without the GNU autotools
The runtest program can be run standalone. All the autoconf/automake support is just cause those
programs are commonly used for other GNU applications. The key to running runtest standalone is
having the local site.exp file setup correctly, which automake does.
The generated site.exp should like like:
set tool calc
set srcdir .
set objdir /home/dgt/dejagnu.test
3.2.2. Using autoconf/autoheader/automake
We have to prepare some input file in order to run autoconf and automake. There is book "GNU
autoconf, automake and libtool" by Garry V. Vaughan, et al. NewRider, ISBN 1-57870-190-2 which
describes this process thoroughly.
From the calc example distributed with the DejaGnu documentation you should copy the program file
itself (calc.c) and some additional files, which you might examine a little bit close to derive their
meanings.
dgt:~/dejagnu.test$ cp -r /usr/share/doc/dejagnu/examples/calc/\
{configure.in,Makefile.am,calc.c,testsuite} .
In Makemake.am note the presence of the AUTOMAKE_OPTIONS = dejagnu. This option is needed.
7
DejaGnu
Run aclocal to generate aclocal.m4, which is a collection of macros needed by configure.in
dgt:~/dejagnu.test$ aclocal
autoconf is another part of the auto-tools. Run it to generate configure based on information contained in
configure.in.
dgt:~/dejagnu.test$ autoconf
autoheader is another part of the auto-tools. Run it to generate calc.h.in.
dgt:~/dejagnu.test$ autoheader
The Makefile.am of this example was developed as port of the DejaGnu distribution. Adapt Makefile.am
for this test. Replace the line "#noinst_PROGRAMS = calc" to "bin_PROGRAMS = calc". Change the
RUNTESTDEFAULTFLAGS from "$$srcdir/testsuite" to "./testsuite".
Running automake at this point contains a series of warning in its output as shown in the following
example:
Example 2. Sample output of automake with missing files
dgt:~/dejagnu.test$ automake --add-missing
automake: configure.in: installing ‘./install-sh’
automake: configure.in: installing ‘./mkinstalldirs’
automake: configure.in: installing ‘./missing’
automake: Makefile.am: installing ‘./INSTALL’
automake: Makefile.am: required file ‘./NEWS’ not found
automake: Makefile.am: required file ‘./README’ not found
automake: Makefile.am: installing ‘./COPYING’
automake: Makefile.am: required file ‘./AUTHORS’ not found
automake: Makefile.am: required file ‘./ChangeLog’ not found
configure.in: 4: required file ‘./calc.h.in’ not found
Makefile.am:6: required directory ./doc does not exist
Create a empty directory doc and empty files INSTALL, NEWS, README, AUTHORS, ChangeLog
and COPYING. The default COPYING will point to the GNU Public License (GPL). In a real project it
would be time to add some meaningful text in each file.
Adapt calc to your environment by calling configure.
Example 3. Sample output of configure
dgt:~/dejagnu.test$ ./configure
creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
8
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
