Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Back: Installing and Uninstalling
Forward: 14.2 Fine-grained control of install
 
FastBack: Installing and Uninstalling
Up: Installing and Uninstalling
FastForward: Writing Portable C
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

14.1 Where files are installed

If you've ever run configure --help, you've probably been frightened by the huge number of options offered. Although nobody ever uses more than two or three of these, they are still important to understand when writing your package; their proper use will help you figure out where each file should be installed. For a background on these standard directories and their uses, refer to 3. How to run configure and make.

We do recommend using the standard directories as described. While most package builders only use `--prefix' or perhaps `--exec-prefix', some packages (eg. GNU/Linux distributions) require more control. For instance, if your package `quux' puts a file into sysconfigdir, then in the default configuration it will end up in `/usr/local/var'. However, for a GNU/Linux distribution it would make more sense to configure with `--sysconfigdir=/var/quux'.

Automake makes it very easy to use the standard directories. Each directory, such as `bindir', is mapped onto a `Makefile' variable of the same name. Automake adds three useful variables to the standard list:

pkgincludedir
This is a convenience variable whose value is `$(includedir)/$(PACKAGE)'.

pkgdatadir
A convenience variable whose value is `$(datadir)/$(PACKAGE)'.

pkglibdir
A variable whose value is `$(libdir)/$(PACKAGE)'.

These cannot be set on the configure command line but are always defined as above. (29)

In Automake, a directory variable's name, without the `dir' suffix, can be used as a prefix to a primary to indicate install location. Confused yet? And example will help: items listed in `bin_PROGRAMS' are installed in `bindir'.

Automake's rules are actually a bit more precise than this: the directory and the primary must agree. It doesn't make sense to install a library in `datadir', so Automake won't let you. Here is a complete list showing primaries and the directories which can be used with them:

`PROGRAMS'
`bindir', `sbindir', `libexecdir', `pkglibdir'.

`LIBRARIES'
`libdir', `pkglibdir'.

`LTLIBRARIES'
`libdir', `pkglibdir'.

`SCRIPTS'
`bindir', `sbindir', `libexecdir', `pkgdatadir'.

`DATA'
`datadir', `sysconfdir', `sharedstatedir', `localstatedir', `pkgdatadir'.

`HEADERS'
`includedir', `oldincludedir', `pkgincludedir'.

`TEXINFOS'
`infodir'.

`MANS'
`man', `man0', `man1', `man2', `man3', `man4', `man5', `man6', `man7', `man8', `man9', `mann', `manl'.

There are two other useful prefixes which, while not directory names, can be used in their place. These prefixes are valid with any primary. The first of these is `noinst'. This prefix tells Automake that the listed objects should not be installed, but should be built anyway. For instance, you can use `noinst_PROGRAMS' to list programs which will not be installed.

The second such non-directory prefix is `check'. This prefix tells Automake that this object should not be installed, and furthermore that it should only be built when the user runs make check.

Early in Automake history we discovered that even Automake's extended built-in list of directories was not enough -- basically anyone who had written a `Makefile.am' sent in a bug report about this. Now Automake lets you extend the list of directories.

First you must define your own directory variable. This is a macro whose name ends in `dir'. Define this variable however you like. We suggest that you define it relative to an autoconf directory variable; this gives the user some control over the value. Don't hardcode it to something like `/etc'; absolute hardcoded paths are rarely portable.

Now you can attach the base part of the new variable to a primary just as you can with the built-in directories:

 
foodir = $(datadir)/foo
foo_DATA = foo.txt

Automake lets you attach such a variable to any primary, so you can do things you ordinarily wouldn't want to do or be allowed to do. For instance, Automake won't diagnose this piece of code that tries to install a program in an architecture-independent location:

 
foodir = $(datadir)/foo
foo_PROGRAMS = foo


This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html

 
 
  Published under the terms of the Open Publication License Design by Interspire