home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 8
/
FreshFishVol8-CD1.bin
/
gnu
/
info
/
autoconf.info-3
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-12-22
|
51KB
|
906 lines
This is Info file /gnu/src/amiga/autoconf-2.1/autoconf.info, produced
by Makeinfo-1.55 from the input file
/gnu/src/amiga/autoconf-2.1/autoconf.texi.
START-INFO-DIR-ENTRY
* Autoconf: (autoconf). Create source code configuration scripts.
END-INFO-DIR-ENTRY
This file documents the GNU Autoconf package for creating scripts to
configure source code packages using templates and an `m4' macro
package.
Copyright (C) 1992, 1993, 1994 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.
File: autoconf.info, Node: Run Time, Next: Portable Shell, Prev: Examining Libraries, Up: Writing Tests
Checking Run Time Behavior
==========================
Sometimes you need to find out how a system performs at run time,
such as whether a given function has a certain capability or bug. If
you can, make such checks when your program runs instead of when it is
configured. You can check for things like the machine's endianness when
your program initializes itself.
If you really need to test for a run-time behavior while configuring,
you can write a test program to determine the result, and compile and
run it using `AC_TRY_RUN'. Avoid running test programs if possible,
because using them prevents people from configuring your package for
cross-compiling.
* Menu:
* Test Programs:: Running test programs.
* Guidelines:: General rules for writing test programs.
* Test Functions:: Avoiding pitfalls in test programs.
File: autoconf.info, Node: Test Programs, Next: Guidelines, Up: Run Time
Running Test Programs
---------------------
Use the following macro if you need to test run-time behavior of the
system while configuring.
- Macro: AC_TRY_RUN (PROGRAM, ACTION-IF-TRUE [, ACTION-IF-FALSE [,
ACTION-IF-CROSS-COMPILING]])
PROGRAM is the text of a C program, on which shell variable and
backquote substitutions are performed. If it compiles and links
successfully and returns an exit status of 0 when executed, run
shell commands ACTION-IF-TRUE. Otherwise run shell commands
ACTION-IF-FALSE; the exit status of the program is available in
the shell variable `$?'. This macro uses `CFLAGS' or `CXXFLAGS',
`CPPFLAGS', `LDFLAGS', and `LIBS' when compiling.
If the C compiler being used does not produce executables that run
on the system where `configure' is being run, then the test
program is not run. If the optional shell commands
ACTION-IF-CROSS-COMPILING are given, they are run instead and this
macro calls `AC_C_CROSS' if it has not already been called.
Otherwise, `configure' prints an error message and exits.
Try to provide a pessimistic default value to use when
cross-compiling makes run-time tests impossible. You do this by
passing the optional last argument to `AC_TRY_RUN'. `autoconf' prints
a warning message when creating `configure' each time it encounters a
call to `AC_TRY_RUN' with no ACTION-IF-CROSS-COMPILING argument given.
You may ignore the warning, though users will not be able to configure
your package for cross-compiling. A few of the macros distributed with
Autoconf produce this warning message.
To configure for cross-compiling you can also choose a value for
those parameters based on the canonical system name (*note Manual
Configuration::.). Alternatively, set up a test results cache file with
the correct values for the target system (*note Caching Results::.).
To provide a default for calls of `AC_TRY_RUN' that are embedded in
other macros, including a few of the ones that come with Autoconf, you
can call `AC_C_CROSS' before running them. Then, if the shell variable
`cross_compiling' is set to `yes', use an alternate method to get the
results instead of calling the macros.
- Macro: AC_C_CROSS
If the C compiler being used does not produce executables that can
run on the system where `configure' is being run, set the shell
variable `cross_compiling' to `yes', otherwise `no'.
File: autoconf.info, Node: Guidelines, Next: Test Functions, Prev: Test Programs, Up: Run Time
Guidelines for Test Programs
----------------------------
Test programs should not write anything to the standard output. They
should return 0 if the test succeeds, nonzero otherwise, so that success
can be distinguished easily from a core dump or other failure;
segmentation violations and other failures produce a nonzero exit
status. Test programs should `exit', not `return', from `main',
because on some systems (old Suns, at least) the argument to `return'
in `main' is ignored.
Test programs can use `#if' or `#ifdef' to check the values of
preprocessor macros defined by tests that have already run. For
example, if you call `AC_HEADER_STDC', then later on in `configure.in'
you can have a test program that includes an ANSI C header file
conditionally:
#if STDC_HEADERS
# include <stdlib.h>
#endif
If a test program needs to use or create a data file, give it a name
that starts with `conftest', such as `conftestdata'. The `configure'
script cleans up by running `rm -rf conftest*' after running test
programs and if the script is interrupted.
File: autoconf.info, Node: Test Functions, Prev: Guidelines, Up: Run Time
Test Functions
--------------
Function declarations in test programs should have a prototype
conditionalized for C++. In practice, though, test programs rarely need
functions that take arguments.
#ifdef __cplusplus
foo(int i)
#else
foo(i) int i;
#endif
Functions that test programs declare should also be conditionalized
for C++, which requires `extern "C"' prototypes. Make sure to not
include any header files containing clashing prototypes.
#ifdef __cplusplus
extern "C" void *malloc(size_t);
#else
char *malloc();
#endif
If a test program calls a function with invalid parameters (just to
see whether it exists), organize the program to ensure that it never
invokes that function. You can do this by calling it in another
function that is never invoked. You can't do it by putting it after a
call to `exit', because GCC version 2 knows that `exit' never returns
and optimizes out any code that follows it in the same block.
If you include any header files, make sure to call the functions
relevant to them with the correct number of arguments, even if they are
just 0, to avoid compilation errors due to prototypes. GCC version 2
has internal prototypes for several functions that it automatically
inlines; for example, `memcpy'. To avoid errors when checking for
them, either pass them the correct number of arguments or redeclare them
with a different return type (such as `char').
File: autoconf.info, Node: Portable Shell, Next: Testing Values and Files, Prev: Run Time, Up: Writing Tests
Portable Shell Programming
==========================
When writing your own checks, there are some shell script programming
techniques you should avoid in order to make your code portable. The
Bourne shell and upward-compatible shells like Bash and the Korn shell
have evolved over the years, but to prevent trouble, do not take
advantage of features that were added after UNIX version 7, circa 1977.
You should not use shell functions, aliases, negated character classes,
or other features that are not found in all Bourne-compatible shells;
restrict yourself to the lowest common denominator. Even `unset' is
not supported by all shells!
The set of external programs you should run in a `configure' script
is fairly small. *Note Utilities in Mak