14.2 Fine-grained control of install

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

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 May, 24 2001 using texi2html


GNU Autoconf, Automake and Libtool
GNU Autoconf, Automake, and Libtool
ISBN: 1578701902
EAN: 2147483647
Year: 2002
Pages: 290

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net