Back: 14.1 Where files are installed
Forward: 14.3 Install hooks
 
FastBack: 14.3 Install hooks
Up: Installing and Uninstalling
FastForward: Writing Portable C
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

14.2 Fine-grained control of install

The second most common way (30) to configure a package is to set prefix and exec-prefix to different values. This way, a system administrator on a heterogenous network can arrange to have the architecture-independent files shared by all platforms. Typically this doesn't save very much space, but it does make in-place bug fixing or platform-independent runtime configuration a lot easier.

To this end, Automake provides finer control to the user than a simple make install. For instance, the user can strip all the package executables at install time by running make install-strip (though we recommend setting the various `INSTALL' environment variables instead; this is discussed later). More importantly, Automake provides a way to install the architecture-dependent and architecture-independent parts of a package independently.

In the above scenario, installing the architecture-independent files more than once is just a waste of time. Our hypothetical administrator can install those pieces exactly once, with make install-data, and then on each type of build machine install only the architecture-dependent files with make install-exec.

Nonstandard directories specified in `Makefile.am' are also separated along `data' and `exec' lines, giving the user complete control over installation. If, and only if, the directory variable name contains the string `exec', then items ending up in that directory will be installed by install-exec and not install-data.

At some sites, the paths referred to by software at runtime differ from those used to actually install the software. For instance, suppose `/usr/local' is mounted read-only throughout the network. On the server, where new packages are built, the file system is available read-write as `/w/usr/local' -- a directory which is not mounted anywhere else. In this situation the sysadmin can configure and build using the runtime values, but use the `DESTDIR' trick to temporarily change the paths at install time:

 
./configure --prefix=/usr/local
make
make DESTDIR=/w install

Note that `DESTDIR' operates as a prefix only. Sometimes this isn't enough. In this situation you can explicitly override each directory variable:

 
./configure --prefix=/usr/local
make
make prefix=/w/usr/local datadir=/w/usr/share install

Here is a full example (31) showing how you can unpack, configure, and build a typical GNU program on multiple machines at the same time:

 
sunos$ tar zxf foo-0.1.tar.gz
sunos$ mkdir sunos linux

In one window:

 
sunos$ cd sunos
sunos$ ../foo-0.1/configure --prefix=/usr/local \
> --exec-prefix=/usr/local/sunos
sunos$ make
sunos$ make install

And in another window:

 
sunos$ rsh linux
linux$ cd ~/linux
linux$ ../foo-0.1/configure --prefix=/usr/local \
> --exec-prefix=/usr/local/linux
linux$ make
linux$ make install-exec

In this example we install everything on the `sunos' machine, but we only install the platform-dependent files on the `linux' machine. We use a different exec-prefix, so for example GNU/Linux executables will end up in `/usr/local/linux/bin/'.


This document was generated by Gary V. Vaughan on November, 13 2000 using texi2html