home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 8
/
FreshFishVol8-CD1.bin
/
gnu
/
info
/
autoconf.info-4
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-12-22
|
49KB
|
858 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: Transforming Names, Next: Site Defaults, Prev: Site Details, Up: Site Configuration
Transforming Program Names When Installing
==========================================
Autoconf supports changing the names of programs when installing
them. In order to use these transformations, `configure.in' must call
the macro `AC_ARG_PROGRAM'.
- Macro: AC_ARG_PROGRAM
Place in output variable `program_transform_name' a sequence of
`sed' commands for changing the names of installed programs.
If any of the options described below are given to `configure',
program names are transformed accordingly. Otherwise, if
`AC_CANONICAL_SYSTEM' has been called and a `--target' value is
given that differs from the host type (specified with `--host' or
defaulted by `config.sub'), the target type followed by a dash is
used as a prefix. Otherwise, no program name transformation is
done.
* Menu:
* Transformation Options:: `configure' options to transforme names.
* Transformation Examples:: Sample uses of transforming names.
* Transformation Rules:: `Makefile' uses of transforming names.
File: autoconf.info, Node: Transformation Options, Next: Transformation Examples, Up: Transforming Names
Transformation Options
----------------------
You can specify name transformations by giving `configure' these
command line options:
`--program-prefix=PREFIX'
prepend PREFIX to the names;
`--program-suffix=SUFFIX'
append SUFFIX to the names;
`--program-transform-name=EXPRESSION'
perform `sed' substitution EXPRESSION on the names.
File: autoconf.info, Node: Transformation Examples, Next: Transformation Rules, Prev: Transformation Options, Up: Transforming Names
Transformation Examples
-----------------------
These transformations are useful with programs that can be part of a
cross-compilation development environment. For example, a
cross-assembler running on a Sun 4 configured with
`--target=i960-vxworks' is normally installed as `i960-vxworks-as',
rather than `as', which could be confused with a native Sun 4 assembler.
You can force a program name to begin with `g', if you don't want
GNU programs installed on your system to shadow other programs with the
same name. For example, if you configure GNU `diff' with
`--program-prefix=g', then when you run `make install' it is installed
as `/usr/local/bin/gdiff'.
As a more sophistocated example, you could use
--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
to prepend `g' to most of the program names in a source tree, excepting
those like `gdb' that already have one and those like `less' and
`lesskey' that aren't GNU programs. (That is assuming that you have a
source tree containing those programs that is set up to use this
feature.)
One way to install multiple versions of some programs simultaneously
is to append a version number to the name of one or both. For example,
if you want to keep Autoconf version 1 around for awhile, you can
configure Autoconf version 2 using `--program-suffix=2' to install the
programs as `/usr/local/bin/autoconf2', `/usr/local/bin/autoheader2',
File: autoconf.info, Node: Transformation Rules, Prev: Transformation Examples, Up: Transforming Names
Transformation Rules
--------------------
Here is how to use the variable `program_transform_name' in a
`Makefile.in':
transform=@program_transform_name@
install: all
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`
uninstall:
rm -f $(bindir)/`echo myprog|sed '$(transform)'`
If you have more than one program to install, you can do it in a loop:
PROGRAMS=cp ls rm
install:
for p in $(PROGRAMS); do \
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
done
uninstall:
for p in $(PROGRAMS); do \
rm -f $(bindir)/`echo $$p|sed '$(transform)'`; \
done
Whether to do the transformations on documentation files (Texinfo or
`man') is a tricky question; there seems to be no perfect answer, due
to the several reasons for name transforming. Documentation is not
usually particular to a specific architecture, and Texinfo files do not
conflict with system documentation. But they might conflict with
earlier versions of the same files, and `man' pages sometimes do
conflict with system documentation. As a compromise, it is probably
best to do name transformations on `man' pages but not on Texinfo
manuals.
File: autoconf.info, Node: Site Defaults, Prev: Transforming Names, Up: Site Configuration
Setting Site Defaults
=====================
Autoconf-generated `configure' scripts allow your site to provide
default values for some configuration values. You do this by creating
site- and system-wide initialization files.
If the environment variable `CONFIG_SITE' is set, `configure' uses
its value as the name of a shell script to read. Otherwise, it reads
the shell script `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Thus, settings in
machine-specific files override those in machine-independent ones in
case of conflict.
Site files can be arbitrary shell scripts, but only certain kinds of
code are really appropriate to be in them. Because `configure' reads
any cache file after it has read any site files, a site file can define
a default cache file to be shared between all Autoconf-generated
`configure' scripts run on that system. If you set a default cache
file in a site file, it is a good idea to also set the output variable
`CC' in that site file, because the cache file is only valid for a
particular compiler, but many systems have several available.
Site files are also good places to set default values for other
output variables, such as `CFLAGS', if you need to give them non-default
values: anything you would normally do, repetitively, on the command
line. If you use non-default values for PREFIX or EXEC_PREFIX
(wherever you locate the site file), you can set them in the site file
if you specify it with the `CONFIG_SITE' environment variable.
You can set some cache values in the site file itself. Doing this is
useful if you are cross-compiling, so it is impossible to check features
that require running a test program. You could "prime the cache" by
setting those values correctly for that system in
`PREFIX/etc/config.site'. To find out the names of the cache variables
you need to set, look for shell variables with `_cv_' in their names in
the affected `configure' scripts, or in the Autoconf `m4' source code
for those macros.
The cache file is careful to not override any variables set in the
site files. Similarly, you should not override command-line options in
the site files. Your code should check that variables such as `prefix'
and `cache_file' have their default values (as set near the top of
`configure') before changing them.
Here is a sample file `/usr/share/local