INSTALL (paps-0.6.8) | : | INSTALL (paps-0.7.1) | ||
---|---|---|---|---|
Installation Instructions | ||||
************************* | ||||
Copyright (C) 1994-1996, 1999-2002, 2004-2016 Free Software | ||||
Foundation, Inc. | ||||
Copying and distribution of this file, with or without modification, | ||||
are permitted in any medium without royalty provided the copyright | ||||
notice and this notice are preserved. This file is offered as-is, | ||||
without warranty of any kind. | ||||
Basic Installation | Basic Installation | |||
================== | ================== | |||
These are generic installation instructions. | Briefly, the shell command './configure && make && make install' | |||
should configure, build, and install this package. The following | ||||
more-detailed instructions are generic; see the 'README' file for | ||||
instructions specific to this package. Some packages provide this | ||||
'INSTALL' file but do not implement all of the features documented | ||||
below. The lack of an optional feature in a given package is not | ||||
necessarily a bug. More recommendations for GNU packages can be found | ||||
in *note Makefile Conventions: (standards)Makefile Conventions. | ||||
The `configure' shell script attempts to guess correct values for | The 'configure' shell script attempts to guess correct values for | |||
various system-dependent variables used during compilation. It uses | various system-dependent variables used during compilation. It uses | |||
those values to create a `Makefile' in each directory of the package. | those values to create a 'Makefile' in each directory of the package. | |||
It may also create one or more `.h' files containing system-dependent | It may also create one or more '.h' files containing system-dependent | |||
definitions. Finally, it creates a shell script `config.status' that | definitions. Finally, it creates a shell script 'config.status' that | |||
you can run in the future to recreate the current configuration, a file | you can run in the future to recreate the current configuration, and a | |||
`config.cache' that saves the results of its tests to speed up | file 'config.log' containing compiler output (useful mainly for | |||
reconfiguring, and a file `config.log' containing compiler output | debugging 'configure'). | |||
(useful mainly for debugging `configure'). | ||||
It can also use an optional file (typically called 'config.cache' and | ||||
enabled with '--cache-file=config.cache' or simply '-C') that saves the | ||||
results of its tests to speed up reconfiguring. Caching is disabled by | ||||
default to prevent problems with accidental use of stale cache files. | ||||
If you need to do unusual things to compile the package, please try | If you need to do unusual things to compile the package, please try | |||
to figure out how `configure' could check whether to do them, and mail | to figure out how 'configure' could check whether to do them, and mail | |||
diffs or instructions to the address given in the `README' so they can | diffs or instructions to the address given in the 'README' so they can | |||
be considered for the next release. If at some point `config.cache' | be considered for the next release. If you are using the cache, and at | |||
contains results you don't want to keep, you may remove or edit it. | some point 'config.cache' contains results you don't want to keep, you | |||
may remove or edit it. | ||||
The file `configure.in' is used to create `configure' by a program | ||||
called `autoconf'. You only need `configure.in' if you want to change | The file 'configure.ac' (or 'configure.in') is used to create | |||
it or regenerate `configure' using a newer version of `autoconf'. | 'configure' by a program called 'autoconf'. You need 'configure.ac' if | |||
you want to change it or regenerate 'configure' using a newer version of | ||||
The simplest way to compile this package is: | 'autoconf'. | |||
1. `cd' to the directory containing the package's source code and type | The simplest way to compile this package is: | |||
`./configure' to configure the package for your system. If you're | ||||
using `csh' on an old version of System V, you might need to type | 1. 'cd' to the directory containing the package's source code and type | |||
`sh ./configure' instead to prevent `csh' from trying to execute | './configure' to configure the package for your system. | |||
`configure' itself. | ||||
Running 'configure' might take a while. While running, it prints | ||||
Running `configure' takes a while. While running, it prints some | some messages telling which features it is checking for. | |||
messages telling which features it is checking for. | ||||
2. Type 'make' to compile the package. | ||||
2. Type `make' to compile the package. | ||||
3. Optionally, type 'make check' to run any self-tests that come with | ||||
3. Type `make install' to install the programs and any data files and | the package, generally using the just-built uninstalled binaries. | |||
documentation. | ||||
4. Type 'make install' to install the programs and any data files and | ||||
4. You can remove the program binaries and object files from the | documentation. When installing into a prefix owned by root, it is | |||
source code directory by typing `make clean'. | recommended that the package be configured and built as a regular | |||
user, and only the 'make install' phase executed with root | ||||
privileges. | ||||
5. Optionally, type 'make installcheck' to repeat any self-tests, but | ||||
this time using the binaries in their final installed location. | ||||
This target does not install anything. Running this target as a | ||||
regular user, particularly if the prior 'make install' required | ||||
root privileges, verifies that the installation completed | ||||
correctly. | ||||
6. You can remove the program binaries and object files from the | ||||
source code directory by typing 'make clean'. To also remove the | ||||
files that 'configure' created (so you can compile the package for | ||||
a different kind of computer), type 'make distclean'. There is | ||||
also a 'make maintainer-clean' target, but that is intended mainly | ||||
for the package's developers. If you use it, you may have to get | ||||
all sorts of other programs in order to regenerate files that came | ||||
with the distribution. | ||||
7. Often, you can also type 'make uninstall' to remove the installed | ||||
files again. In practice, not all packages have tested that | ||||
uninstallation works correctly, even though it is required by the | ||||
GNU Coding Standards. | ||||
8. Some packages, particularly those that use Automake, provide 'make | ||||
distcheck', which can by used by developers to test that all other | ||||
targets like 'make install' and 'make uninstall' work correctly. | ||||
This target is generally not run by end users. | ||||
Compilers and Options | Compilers and Options | |||
===================== | ===================== | |||
Some systems require unusual options for compilation or linking that | Some systems require unusual options for compilation or linking that | |||
the `configure' script does not know about. You can give `configure' | the 'configure' script does not know about. Run './configure --help' | |||
initial values for variables by setting them in the environment. Using | for details on some of the pertinent environment variables. | |||
a Bourne-compatible shell, you can do that on the command line like | ||||
this: | ||||
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure | ||||
Or on systems that have the `env' program, you can do it like this: | You can give 'configure' initial values for configuration parameters | |||
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure | by setting variables in the command line or in the environment. Here is | |||
an example: | ||||
./configure CC=c99 CFLAGS=-g LIBS=-lposix | ||||
*Note Defining Variables::, for more details. | ||||
Compiling For Multiple Architectures | Compiling For Multiple Architectures | |||
==================================== | ==================================== | |||
You can compile the package for more than one kind of computer at the | You can compile the package for more than one kind of computer at the | |||
same time, by placing the object files for each architecture in their | same time, by placing the object files for each architecture in their | |||
own directory. To do this, you must use a version of `make' that | own directory. To do this, you can use GNU 'make'. 'cd' to the | |||
supports the `VPATH' variable, such as GNU `make'. `cd' to the | ||||
directory where you want the object files and executables to go and run | directory where you want the object files and executables to go and run | |||
the `configure' script. `configure' automatically checks for the | the 'configure' script. 'configure' automatically checks for the source | |||
source code in the directory that `configure' is in and in `..'. | code in the directory that 'configure' is in and in '..'. This is known | |||
as a "VPATH" build. | ||||
With a non-GNU 'make', it is safer to compile the package for one | ||||
architecture at a time in the source code directory. After you have | ||||
installed the package for one architecture, use 'make distclean' before | ||||
reconfiguring for another architecture. | ||||
On MacOS X 10.5 and later systems, you can create libraries and | ||||
executables that work on multiple system types--known as "fat" or | ||||
"universal" binaries--by specifying multiple '-arch' options to the | ||||
compiler but only a single '-arch' option to the preprocessor. Like | ||||
this: | ||||
If you have to use a `make' that does not supports the `VPATH' | ./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ | |||
variable, you have to compile the package for one architecture at a time | CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ | |||
in the source code directory. After you have installed the package for | CPP="gcc -E" CXXCPP="g++ -E" | |||
one architecture, use `make distclean' before reconfiguring for another | ||||
architecture. | This is not guaranteed to produce working output in all cases, you | |||
may have to build one architecture at a time and combine the results | ||||
using the 'lipo' tool if you have problems. | ||||
Installation Names | Installation Names | |||
================== | ================== | |||
By default, `make install' will install the package's files in | By default, 'make install' installs the package's commands under | |||
`/usr/local/bin', `/usr/local/man', etc. You can specify an | '/usr/local/bin', include files under '/usr/local/include', etc. You | |||
installation prefix other than `/usr/local' by giving `configure' the | can specify an installation prefix other than '/usr/local' by giving | |||
option `--prefix=PATH'. | 'configure' the option '--prefix=PREFIX', where PREFIX must be an | |||
absolute file name. | ||||
You can specify separate installation prefixes for | You can specify separate installation prefixes for | |||
architecture-specific files and architecture-independent files. If you | architecture-specific files and architecture-independent files. If you | |||
give `configure' the option `--exec-prefix=PATH', the package will use | pass the option '--exec-prefix=PREFIX' to 'configure', the package uses | |||
PATH as the prefix for installing programs and libraries. | PREFIX as the prefix for installing programs and libraries. | |||
Documentation and other data files will still use the regular prefix. | Documentation and other data files still use the regular prefix. | |||
If the package supports it, you can cause programs to be installed | In addition, if you use an unusual directory layout you can give | |||
with an extra prefix or suffix on their names by giving `configure' the | options like '--bindir=DIR' to specify different values for particular | |||
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'. | kinds of files. Run 'configure --help' for a list of the directories | |||
you can set and what kinds of files go in them. In general, the default | ||||
for these options is expressed in terms of '${prefix}', so that | ||||
specifying just '--prefix' will affect all of the other directory | ||||
specifications that were not explicitly provided. | ||||
The most portable way to affect installation locations is to pass the | ||||
correct locations to 'configure'; however, many packages provide one or | ||||
both of the following shortcuts of passing variable assignments to the | ||||
'make install' command line to change installation locations without | ||||
having to reconfigure or recompile. | ||||
The first method involves providing an override variable for each | ||||
affected directory. For example, 'make install | ||||
prefix=/alternate/directory' will choose an alternate location for all | ||||
directory configuration variables that were expressed in terms of | ||||
'${prefix}'. Any directories that were specified during 'configure', | ||||
but not in terms of '${prefix}', must each be overridden at install time | ||||
for the entire installation to be relocated. The approach of makefile | ||||
variable overrides for each directory variable is required by the GNU | ||||
Coding Standards, and ideally causes no recompilation. However, some | ||||
platforms have known limitations with the semantics of shared libraries | ||||
that end up requiring recompilation when using this method, particularly | ||||
noticeable in packages that use GNU Libtool. | ||||
The second method involves providing the 'DESTDIR' variable. For | ||||
example, 'make install DESTDIR=/alternate/directory' will prepend | ||||
'/alternate/directory' before all installation names. The approach of | ||||
'DESTDIR' overrides is not required by the GNU Coding Standards, and | ||||
does not work on platforms that have drive letters. On the other hand, | ||||
it does better at avoiding recompilation issues, and works well even | ||||
when some directory options were not specified in terms of '${prefix}' | ||||
at 'configure' time. | ||||
Optional Features | Optional Features | |||
================= | ================= | |||
Some packages pay attention to `--enable-FEATURE' options to | If the package supports it, you can cause programs to be installed | |||
`configure', where FEATURE indicates an optional part of the package. | with an extra prefix or suffix on their names by giving 'configure' the | |||
They may also pay attention to `--with-PACKAGE' options, where PACKAGE | option '--program-prefix=PREFIX' or '--program-suffix=SUFFIX'. | |||
is something like `gnu-as' or `x' (for the X Window System). The | ||||
`README' should mention any `--enable-' and `--with-' options that the | Some packages pay attention to '--enable-FEATURE' options to | |||
'configure', where FEATURE indicates an optional part of the package. | ||||
They may also pay attention to '--with-PACKAGE' options, where PACKAGE | ||||
is something like 'gnu-as' or 'x' (for the X Window System). The | ||||
'README' should mention any '--enable-' and '--with-' options that the | ||||
package recognizes. | package recognizes. | |||
For packages that use the X Window System, `configure' can usually | For packages that use the X Window System, 'configure' can usually | |||
find the X include and library files automatically, but if it doesn't, | find the X include and library files automatically, but if it doesn't, | |||
you can use the `configure' options `--x-includes=DIR' and | you can use the 'configure' options '--x-includes=DIR' and | |||
`--x-libraries=DIR' to specify their locations. | '--x-libraries=DIR' to specify their locations. | |||
Some packages offer the ability to configure how verbose the | ||||
execution of 'make' will be. For these packages, running './configure | ||||
--enable-silent-rules' sets the default to minimal output, which can be | ||||
overridden with 'make V=1'; while running './configure | ||||
--disable-silent-rules' sets the default to verbose, which can be | ||||
overridden with 'make V=0'. | ||||
Particular systems | ||||
================== | ||||
On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC | ||||
is not installed, it is recommended to use the following options in | ||||
order to use an ANSI C compiler: | ||||
./configure CC="cc -Ae -D_XOPEN_SOURCE=500" | ||||
and if that doesn't work, install pre-built binaries of GCC for HP-UX. | ||||
HP-UX 'make' updates targets which have the same time stamps as their | ||||
prerequisites, which makes it generally unusable when shipped generated | ||||
files such as 'configure' are involved. Use GNU 'make' instead. | ||||
On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot | ||||
parse its '<wchar.h>' header file. The option '-nodtk' can be used as a | ||||
workaround. If GNU CC is not installed, it is therefore recommended to | ||||
try | ||||
./configure CC="cc" | ||||
and if that doesn't work, try | ||||
./configure CC="cc -nodtk" | ||||
On Solaris, don't put '/usr/ucb' early in your 'PATH'. This | ||||
directory contains several dysfunctional programs; working variants of | ||||
these programs are available in '/usr/bin'. So, if you need '/usr/ucb' | ||||
in your 'PATH', put it _after_ '/usr/bin'. | ||||
On Haiku, software installed for all users goes in '/boot/common', | ||||
not '/usr/local'. It is recommended to use the following options: | ||||
./configure --prefix=/boot/common | ||||
Specifying the System Type | Specifying the System Type | |||
========================== | ========================== | |||
There may be some features `configure' can not figure out | There may be some features 'configure' cannot figure out | |||
automatically, but needs to determine by the type of host the package | automatically, but needs to determine by the type of machine the package | |||
will run on. Usually `configure' can figure that out, but if it prints | will run on. Usually, assuming the package is built to be run on the | |||
a message saying it can not guess the host type, give it the | _same_ architectures, 'configure' can figure that out, but if it prints | |||
`--host=TYPE' option. TYPE can either be a short name for the system | a message saying it cannot guess the machine type, give it the | |||
type, such as `sun4', or a canonical name with three fields: | '--build=TYPE' option. TYPE can either be a short name for the system | |||
type, such as 'sun4', or a canonical name which has the form: | ||||
CPU-COMPANY-SYSTEM | CPU-COMPANY-SYSTEM | |||
See the file `config.sub' for the possible values of each field. If | where SYSTEM can have one of these forms: | |||
`config.sub' isn't included in this package, then this package doesn't | ||||
need to know the host type. | OS | |||
KERNEL-OS | ||||
If you are building compiler tools for cross-compiling, you can also | ||||
use the `--target=TYPE' option to select the type of system they will | See the file 'config.sub' for the possible values of each field. If | |||
produce code for and the `--build=TYPE' option to select the type of | 'config.sub' isn't included in this package, then this package doesn't | |||
system on which you are compiling the package. | need to know the machine type. | |||
If you are _building_ compiler tools for cross-compiling, you should | ||||
use the option '--target=TYPE' to select the type of system they will | ||||
produce code for. | ||||
If you want to _use_ a cross compiler, that generates code for a | ||||
platform different from the build platform, you should specify the | ||||
"host" platform (i.e., that on which the generated programs will | ||||
eventually be run) with '--host=TYPE'. | ||||
Sharing Defaults | Sharing Defaults | |||
================ | ================ | |||
If you want to set default values for `configure' scripts to share, | If you want to set default values for 'configure' scripts to share, | |||
you can create a site shell script called `config.site' that gives | you can create a site shell script called 'config.site' that gives | |||
default values for variables like `CC', `cache_file', and `prefix'. | default values for variables like 'CC', 'cache_file', and 'prefix'. | |||
`configure' looks for `PREFIX/share/config.site' if it exists, then | 'configure' looks for 'PREFIX/share/config.site' if it exists, then | |||
`PREFIX/etc/config.site' if it exists. Or, you can set the | 'PREFIX/etc/config.site' if it exists. Or, you can set the | |||
`CONFIG_SITE' environment variable to the location of the site script. | 'CONFIG_SITE' environment variable to the location of the site script. | |||
A warning: not all `configure' scripts look for a site script. | A warning: not all 'configure' scripts look for a site script. | |||
Operation Controls | Defining Variables | |||
================== | ================== | |||
`configure' recognizes the following options to control how it | Variables not defined in a site shell script can be set in the | |||
environment passed to 'configure'. However, some packages may run | ||||
configure again during the build, and the customized values of these | ||||
variables may be lost. In order to avoid this problem, you should set | ||||
them in the 'configure' command line, using 'VAR=value'. For example: | ||||
./configure CC=/usr/local2/bin/gcc | ||||
causes the specified 'gcc' to be used as the C compiler (unless it is | ||||
overridden in the site shell script). | ||||
Unfortunately, this technique does not work for 'CONFIG_SHELL' due to an | ||||
Autoconf limitation. Until the limitation is lifted, you can use this | ||||
workaround: | ||||
CONFIG_SHELL=/bin/bash ./configure CONFIG_SHELL=/bin/bash | ||||
'configure' Invocation | ||||
====================== | ||||
'configure' recognizes the following options to control how it | ||||
operates. | operates. | |||
`--cache-file=FILE' | '--help' | |||
Use and save the results of the tests in FILE instead of | '-h' | |||
`./config.cache'. Set FILE to `/dev/null' to disable caching, for | Print a summary of all of the options to 'configure', and exit. | |||
debugging `configure'. | ||||
'--help=short' | ||||
`--help' | '--help=recursive' | |||
Print a summary of the options to `configure', and exit. | Print a summary of the options unique to this package's | |||
'configure', and exit. The 'short' variant lists options used only | ||||
`--quiet' | in the top level, while the 'recursive' variant lists options also | |||
`--silent' | present in any nested packages. | |||
`-q' | ||||
Do not print messages saying which checks are being made. | '--version' | |||
'-V' | ||||
Print the version of Autoconf used to generate the 'configure' | ||||
script, and exit. | ||||
`--srcdir=DIR' | '--cache-file=FILE' | |||
Enable the cache: use and save the results of the tests in FILE, | ||||
traditionally 'config.cache'. FILE defaults to '/dev/null' to | ||||
disable caching. | ||||
'--config-cache' | ||||
'-C' | ||||
Alias for '--cache-file=config.cache'. | ||||
'--quiet' | ||||
'--silent' | ||||
'-q' | ||||
Do not print messages saying which checks are being made. To | ||||
suppress all normal output, redirect it to '/dev/null' (any error | ||||
messages will still be shown). | ||||
'--srcdir=DIR' | ||||
Look for the package's source code in directory DIR. Usually | Look for the package's source code in directory DIR. Usually | |||
`configure' can determine that directory automatically. | 'configure' can determine that directory automatically. | |||
`--version' | '--prefix=DIR' | |||
Print the version of Autoconf used to generate the `configure' | Use DIR as the installation prefix. *note Installation Names:: for | |||
script, and exit. | more details, including other options available for fine-tuning the | |||
installation locations. | ||||
'--no-create' | ||||
'-n' | ||||
Run the configure checks, but stop before creating any output | ||||
files. | ||||
`configure' also accepts some other, not widely useful, options. | 'configure' also accepts some other, not widely useful, options. Run | |||
'configure --help' for more details. | ||||
End of changes. 25 change blocks. | ||||
111 lines changed or deleted | 312 lines changed or added |