Source: http://www.gnu.org/prep/standards/

中文: http://www.linuxforum.net/books/gcodestd.html

1 About the GNU Coding Standards

The GNU Hello program serves as an example of how to follow the GNU coding standards for a trivial program. http://www.gnu.org/software/hello/hello.html.

2 Keeping Free Software Free

2.1 Referring to Proprietary Programs

Don’t in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)

2.2 Accepting Contributions

If the program you are working on is copyrighted by the Free Software Foundation, then when someone else sends you a piece of code to add to the program, we need legal papers to use it—just as we asked you to sign papers initially. Each person who makes a nontrivial contribution to a program must sign some sort of legal papers in order for us to have clear title to the program; the main author alone is not enough

3 General Program Design

3.1 Which Languages to Use

The standard extensibility interpreter for GNU software is Guile (http://www.gnu.org/software/guile/), which implements the language Scheme (an especially clean and simple dialect of Lisp).

3.2 Compatibility with Other Implementations

With occasional exceptions, utility programs and libraries for GNU should be upward compatible with those in Berkeley Unix, and upward compatible with Standard C if Standard C specifies their behavior, and upward compatible with POSIX if POSIX specifies their behavior.

3.4 Standard C and Pre-Standard C

However, it is easy to support pre-standard compilers in most programs, so if you know how to do that, feel free. If a program you are maintaining has such support, you should try to keep it working.

To support pre-standard C, instead of writing function definitions in standard prototype form,

int
foo (int x, int y)
…

write the definition in pre-standard style like this,

int
foo (x, y)
 int x, y;
…

and use a separate declaration to specify the argument prototype:

int foo (int, int);

You need such a declaration anyway, in a header file, to get the benefit of prototypes in all the files where the function is called. And once you have the declaration, you normally lose nothing by writing the function definition in the pre-standard style.

This technique does not work for integer types narrower than int. If you think of an argument as being of a type narrower than int, declare it as int instead.

There are a few special cases where this technique is hard to use. For example, if a function argument needs to hold the system type dev_t, you run into trouble, because dev_tis shorter than int on some machines; but you cannot use int instead, because dev_t is wider than int on some machines. There is no type you can safely use on all machines in a non-standard definition. The only way to support non-standard C and pass such an argument is to check the width of dev_t using Autoconf and choose the argument type accordingly. This may not be worth the trouble.

In order to support pre-standard compilers that do not recognize prototypes, you may want to use a preprocessor macro like this:

/* Declare the prototype for a general external function. */
#if defined (__STDC__) || defined (WINDOWSNT)
#define P_(proto) proto
#else
#define P_(proto) ()
#endif

3.5 Conditional Compilation

For example, please write

 if (HAS_FOO)
 ...
 else
 ...

instead of:

 #ifdef HAS_FOO
 ...
 #else
 ...
 #endif

A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects. Of course, the former method assumes that HAS_FOO is defined as either 0 or 1.

While this is not a silver bullet solving all portability problems, and is not always appropriate, following this policy would have saved GCC developers many hours, or even days, per year.

In the case of function-like macros like REVERSIBLE_CC_MODE in GCC which cannot be simply used in if (...) statements, there is an easy workaround. Simply introduce another macro HAS_REVERSIBLE_CC_MODE as in the following example:

 #ifdef REVERSIBLE_CC_MODE
 #define HAS_REVERSIBLE_CC_MODE 1
 #else
 #define HAS_REVERSIBLE_CC_MODE 0
 #endif

4 Program Behavior for All Programs

4.1 Non-GNU Standards

POSIX.2 specifies that ‘df

’ and ‘
du

’ must output sizes by default in units of 512 bytes. What users want is units of 1k, so that is what we do by default. If you want the ridiculous behavior “required” by POSIX, you must set the environment variable ‘
POSIXLY_CORRECT

’ (which was originally going to be named ‘
POSIX_ME_HARDER

’).

4.2 Writing Robust Programs

Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility.

Utilities reading files should not drop NUL characters, or any other nonprinting characters including those with codes above 0177. The only sensible exceptions would be utilities specifically intended for interface to certain types of terminals or printers that can’t handle those characters. Whenever possible, try to make programs work properly with sequences of bytes that represent multibyte characters, using encodings such as UTF-8 and others.

Check every system call for an error return, unless you know you wish to ignore errors. Include the system error text (from perror, strerror, or equivalent) in every error message resulting from a failing system call, as well as the name of the file if any and the name of the utility. Just “cannot open foo.c” or “stat failed” is not sufficient.

Check every call to malloc or realloc to see if it returned zero. Check realloc even if you are making the block smaller; in a system that rounds block sizes to a power of 2,realloc may get a different block if you ask for less space.

In Unix, realloc can destroy the storage block if it returns zero. GNU realloc does not have this bug: if it fails, the original block is unchanged. Feel free to assume the bug is fixed. If you wish to run your program on Unix, and wish to avoid lossage in this case, you can use the GNU malloc.

You must expect free to alter the contents of the block that was freed. Anything you want to fetch from the block, you must fetch before calling free.

If malloc fails in a noninteractive program, make that a fatal error. In an interactive program (one that reads commands from the user), it is better to abort the command and return to the command reader loop. This allows the user to kill other processes to free up virtual memory, and then try the command again.

Use getopt_long to decode arguments, unless the argument syntax makes this unreasonable.

When static storage is to be written in during program execution, use explicit C code to initialize it. Reserve C initialized declarations for data that will not be changed.

Try to avoid low-level interfaces to obscure Unix data structures (such as file directories, utmp, or the layout of kernel memory), since these are less likely to work compatibly. If you need to find all the files in a directory, use readdir or some other high-level interface. These are supported compatibly by GNU.

The preferred signal handling facilities are the BSD variant of signal, and the POSIX sigaction function; the alternative USG signal interface is an inferior design.

Nowadays, using the POSIX signal functions may be the easiest way to make a program portable. If you use signal, then on GNU/Linux systems running GNU libc version 1, you should include ‘bsd/signal.h’ instead of ‘signal.h’, so as to get BSD behavior. It is up to you whether to support systems where signal has only the USG behavior, or give up on them.

In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message. These checks indicate the existence of bugs. Whoever wants to fix the bugs will have to read the source code and run a debugger. So explain the problem with comments in the source. The relevant data will be in variables, which are easy to examine with the debugger, so there is no point moving them elsewhere.

Do not use a count of errors as the exit status for a program. That does not work, because exit status values are limited to 8 bits (0 through 255). A single run of the program might have 256 errors; if you try to return 256 as the exit status, the parent process will see 0 as the status, and it will appear that the program succeeded.

If you make temporary files, check the TMPDIR environment variable; if that variable is defined, use the specified directory instead of ‘/tmp’.

In addition, be aware that there is a possible security problem when creating temporary files in world-writable directories. In C, you can avoid this problem by creating temporary files in this manner:

fd = open (filename, O_WRONLY | O_CREAT | O_EXCL, 0600);

or by using the mkstemps function from Gnulib (see mkstemps in Gnulib).

In bash, use set -C (long name noclobber) to avoid this problem. In addition, the mktemp utility is a more general solution for creating temporary files from shell scripts (seemktemp invocation in GNU Coreutils).

4.4 Formatting Error Messages

Error messages from compilers should look like this:

source-file-name:lineno: message

If you want to mention the column number, use one of these formats:

source-file-name:lineno:column: message
source-file-name:lineno.column: message

Line numbers should start from 1 at the beginning of the file, and column numbers should start from 1 at the beginning of the line. (Both of these conventions are chosen for compatibility.) Calculate column numbers assuming that space and all ASCII printing characters have equal width, and assuming tab stops every 8 columns.

The error message can also give both the starting and ending positions of the erroneous text. There are several formats so that you can avoid redundant information such as a duplicate line number. Here are the possible formats:

source-file-name:lineno-1.column-1-lineno-2.column-2: message
source-file-name:lineno-1.column-1-column-2: message
source-file-name:lineno-1-lineno-2: message

When an error is spread over several files, you can use this format:

file-1:lineno-1.column-1-file-2:lineno-2.column-2: message

Error messages from other noninteractive programs should look like this:

program:source-file-name:lineno: message

when there is an appropriate source file, or like this:

program: message

when there is no relevant source file.

If you want to mention the column number, use this format:

program:source-file-name:lineno:column: message

4.7 Standards for Command Line Interfaces

It is a good idea to follow the POSIX guidelines for the command-line options of a program. The easiest way to do this is to use getopt to parse them. Note that the GNU version of getopt will normally permit options anywhere among the arguments unless the special argument ‘
—

’ is used. This is not what POSIX specifies; it is a GNU extension.

Please define long-named options that are equivalent to the single-letter Unix-style options. We hope to make GNU more user friendly this way. This is easy to do with the GNU function getopt_long.

One of the advantages of long-named options is that they can be consistent from program to program. For example, users should be able to expect the “verbose” option of any GNU program which has one, to be spelled precisely ‘
–verbose

’. To achieve this uniformity, look at the table of common long-option names when you choose the option names for your program (see Option Table).

4.7.1 ‘
–version

’

Here’s an example of output that follows these rules:

GNU hello 2.3
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

You should adapt this to your program, of course, filling in the proper year, copyright holder, name of program, and the references to distribution terms, and changing the rest of the wording as necessary.

More information about these licenses and many more are on the GNU licensing web pages, http://www.gnu.org/licenses/license-list.html.

4.7.2 ‘
–help

’

The standard --help option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘
–help

’ option’s output, please place lines giving the email address for bug reports, the package’s home page (normally <http://www.gnu.org/software/pkg>, and the general page for help using GNU programs. The format should be like this:

Report bugs to: mailing-address
pkg home page: <http://www.gnu.org/software/pkg/>
General help using GNU software: <http://www.gnu.org/gethelp/>

4.8 Standards for Dynamic Plug-in Interfaces

Second, you should require plug-in developers to affirm that their plug-ins are released under an appropriate license. This should be enforced with a simple programmatic check. For GCC, again for example, a plug-in must define the global symbol plugin_is_GPL_compatible, thus asserting that the plug-in is released under a GPL-compatible license (see Plugins in GCC Internals).

4.9 Table of Long Options

Here is a table of long options used by GNU programs. It is surely incomplete, but we aim to list all the options that a new program might want to be compatible with. If you use names not already in the table, please send bug-standards@gnu.org a list of them, with their meanings, so we can update the table.

‘
after-date

’

‘
-N

’ in tar.

‘
all

’

‘
-a

’ in du, ls, nm, stty, uname, and unexpand.

‘
all-text

’

‘
-a

’ in diff.

‘
almost-all

’

‘
-A

’ in ls.

‘
append

’

‘
-a

’ in etags, tee, time; ‘
-r

’ in tar.

‘
archive

’

‘
-a

’ in cp.

‘
archive-name

’

‘
-n

’ in shar.

‘
arglength

’

‘
-l

’ in m4.

‘
ascii

’

‘
-a

’ in diff.

‘
assign

’

‘
-v

’ in gawk.

‘
assume-new

’

‘
-W

’ in make.

‘
assume-old

’

‘
-o

’ in make.

‘
auto-check

’

‘
-a

’ in recode.

‘
auto-pager

’

‘
-a

’ in wdiff.

‘
auto-reference

’

‘
-A

’ in ptx.

‘
avoid-wraps

’

‘
-n

’ in wdiff.

‘
background

’

For server programs, run in the background.

‘
backward-search

’

‘
-B

’ in ctags.

‘
basename

’

‘
-f

’ in shar.

‘
batch

’

Used in GDB.

‘
baud

’

Used in GDB.

‘
before

’

‘
-b

’ in tac.

‘
binary

’

‘
-b

’ in cpio and diff.

‘
bits-per-code

’

‘
-b

’ in shar.

‘
block-size

’

Used in cpio and tar.

‘
blocks

’

‘
-b

’ in head and tail.

‘
break-file

’

‘
-b

’ in ptx.

‘
brief

’

Used in various programs to make output shorter.

‘
bytes

’

‘
-c

’ in head, split, and tail.

‘
c

++’

‘
-C

’ in etags.

‘
catenate

’

‘
-A

’ in tar.

‘
cd

’

Used in various programs to specify the directory to use.

‘
changes

’

‘
-c

’ in chgrp and chown.

‘
classify

’

‘
-F

’ in ls.

‘
colons

’

‘
-c

’ in recode.

‘
command

’

‘
-c

’ in su; ‘
-x

’ in GDB.

‘
compare

’

‘
-d

’ in tar.

‘
compat

’

Used in gawk.

‘
compress

’

‘
-Z

’ in tar and shar.

‘
concatenate

’

‘
-A

’ in tar.

‘
confirmation

’

‘
-w

’ in tar.

‘
context

’

Used in diff.

‘
copyleft

’

‘
-W copyleft

’ in gawk.

‘
copyright

’

‘
-C

’ in ptx, recode, and wdiff; ‘
-W copyright

’ in gawk.

‘
core

’

Used in GDB.

‘
count

’

‘
-q

’ in who.

‘
count-links

’

‘
-l

’ in du.

‘
create

’

Used in tar and cpio.

‘
cut-mark

’

‘
-c

’ in shar.

‘
cxref

’

‘
-x

’ in ctags.

‘
date

’

‘
-d

’ in touch.

‘
debug

’

‘
-d

’ in make and m4; ‘
-t

’ in Bison.

‘
define

’

‘
-D

’ in m4.

‘
defines

’

‘
-d

’ in Bison and ctags.

‘
delete

’

‘
-D

’ in tar.

‘
dereference

’

‘
-L

’ in chgrp, chown, cpio, du, ls, and tar.

‘
dereference-args

’

‘
-D

’ in du.

‘
device

’

Specify an I/O device (special file name).

‘
diacritics

’

‘
-d

’ in recode.

‘
dictionary-order

’

‘
-d

’ in look.

‘
diff

’

‘
-d

’ in tar.

‘
digits

’

‘
-n

’ in csplit.

‘
directory

’

Specify the directory to use, in various programs. In ls, it means to show directories themselves rather than their contents. In rm and ln, it means to not treat links to directories specially.

‘
discard-all

’

‘
-x

’ in strip.

‘
discard-locals

’

‘
-X

’ in strip.

‘
dry-run

’

‘
-n

’ in make.

‘
ed

’

‘
-e

’ in diff.

‘
elide-empty-files

’

‘
-z

’ in csplit.

‘
end-delete

’

‘
-x

’ in wdiff.

‘
end-insert

’

‘
-z

’ in wdiff.

‘
entire-new-file

’

‘
-N

’ in diff.

‘
environment-overrides

’

‘
-e

’ in make.

‘
eof

’

‘
-e

’ in xargs.

‘
epoch

’

Used in GDB.

‘
error-limit

’

Used in makeinfo.

‘
error-output

’

‘
-o

’ in m4.

‘
escape

’

‘
-b

’ in ls.

‘
exclude-from

’

‘
-X

’ in tar.

‘
exec

’

Used in GDB.

‘
exit

’

‘
-x

’ in xargs.

‘
exit-0

’

‘
-e

’ in unshar.

‘
expand-tabs

’

‘
-t

’ in diff.

‘
expression

’

‘
-e

’ in sed.

‘
extern-only

’

‘
-g

’ in nm.

‘
extract

’

‘
-i

’ in cpio; ‘
-x

’ in tar.

‘
faces

’

‘
-f

’ in finger.

‘
fast

’

‘
-f

’ in su.

‘
fatal-warnings

’

‘
-E

’ in m4.

‘
file

’

‘
-f

’ in gawk, info, make, mt, sed, and tar.

‘
field-separator

’

‘
-F

’ in gawk.

‘
file-prefix

’

‘
-b

’ in Bison.

‘
file-type

’

‘
-F

’ in ls.

‘
files-from

’

‘
-T

’ in tar.

‘
fill-column

’

Used in makeinfo.

‘
flag-truncation

’

‘
-F

’ in ptx.

‘
fixed-output-files

’

‘
-y

’ in Bison.

‘
follow

’

‘
-f

’ in tail.

‘
footnote-style

’

Used in makeinfo.

‘
force

’

‘
-f

’ in cp, ln, mv, and rm.

‘
force-prefix

’

‘
-F

’ in shar.

‘
foreground

’

For server programs, run in the foreground; in other words, don’t do anything special to run the server in the background.

‘
format

’

Used in ls, time, and ptx.

‘
freeze-state

’

‘
-F

’ in m4.

‘
fullname

’

Used in GDB.

‘
gap-size

’

‘
-g

’ in ptx.

‘
get

’

‘
-x

’ in tar.

‘
graphic

’

‘
-i

’ in ul.

‘
graphics

’

‘
-g

’ in recode.

‘
group

’

‘
-g

’ in install.

‘
gzip

’

‘
-z

’ in tar and shar.

‘
hashsize

’

‘
-H

’ in m4.

‘
header

’

‘
-h

’ in objdump and recode

‘
heading

’

‘
-H

’ in who.

‘
help

’

Used to ask for brief usage information.

‘
here-delimiter

’

‘
-d

’ in shar.

‘
hide-control-chars

’

‘
-q

’ in ls.

‘
html

’

In makeinfo, output HTML.

‘
idle

’

‘
-u

’ in who.

‘
ifdef

’

‘
-D

’ in diff.

‘
ignore

’

‘
-I

’ in ls; ‘
-x

’ in recode.

‘
ignore-all-space

’

‘
-w

’ in diff.

‘
ignore-backups

’

‘
-B

’ in ls.

‘
ignore-blank-lines

’

‘
-B

’ in diff.

‘
ignore-case

’

‘
-f

’ in look and ptx; ‘
-i

’ in diff and wdiff.

‘
ignore-errors

’

‘
-i

’ in make.

‘
ignore-file

’

‘
-i

’ in ptx.

‘
ignore-indentation

’

‘
-I

’ in etags.

‘
ignore-init-file

’

‘
-f

’ in Oleo.

‘
ignore-interrupts

’

‘
-i

’ in tee.

‘
ignore-matching-lines

’

‘
-I

’ in diff.

‘
ignore-space-change

’

‘
-b

’ in diff.

‘
ignore-zeros

’

‘
-i

’ in tar.

‘
include

’

‘
-i

’ in etags; ‘
-I

’ in m4.

‘
include-dir

’

‘
-I

’ in make.

‘
incremental

’

‘
-G

’ in tar.

‘
info

’

‘
-i

’, ‘
-l

’, and ‘
-m

’ in Finger.

‘
init-file

’

In some programs, specify the name of the file to read as the user’s init file.

‘
initial

’

‘
-i

’ in expand.

‘
initial-tab

’

‘
-T

’ in diff.

‘
inode

’

‘
-i

’ in ls.

‘
interactive

’

‘
-i

’ in cp, ln, mv, rm; ‘
-e

’ in m4; ‘
-p

’ in xargs; ‘
-w

’ in tar.

‘
intermix-type

’

‘
-p

’ in shar.

‘
iso-8601

’

Used in date

‘
jobs

’

‘
-j

’ in make.

‘
just-print

’

‘
-n

’ in make.

‘
keep-going

’

‘
-k

’ in make.

‘
keep-files

’

‘
-k

’ in csplit.

‘
kilobytes

’

‘
-k

’ in du and ls.

‘
language

’

‘
-l

’ in etags.

‘
less-mode

’

‘
-l

’ in wdiff.

‘
level-for-gzip

’

‘
-g

’ in shar.

‘
line-bytes

’

‘
-C

’ in split.

‘
lines

’

Used in split, head, and tail.

‘
link

’

‘
-l

’ in cpio.

‘
lint

’

‘
lint-old

’

Used in gawk.

‘
list

’

‘
-t

’ in cpio; ‘
-l

’ in recode.

‘
list

’

‘
-t

’ in tar.

‘
literal

’

‘
-N

’ in ls.

‘
load-average

’

‘
-l

’ in make.

‘
login

’

Used in su.

‘
machine

’

Used in uname.

‘
macro-name

’

‘
-M

’ in ptx.

‘
mail

’

‘
-m

’ in hello and uname.

‘
make-directories

’

‘
-d

’ in cpio.

‘
makefile

’

‘
-f

’ in make.

‘
mapped

’

Used in GDB.

‘
max-args

’

‘
-n

’ in xargs.

‘
max-chars

’

‘
-n

’ in xargs.

‘
max-lines

’

‘
-l

’ in xargs.

‘
max-load

’

‘
-l

’ in make.

‘
max-procs

’

‘
-P

’ in xargs.

‘
mesg

’

‘
-T

’ in who.

‘
message

’

‘
-T

’ in who.

‘
minimal

’

‘
-d

’ in diff.

‘
mixed-uuencode

’

‘
-M

’ in shar.

‘
mode

’

‘
-m

’ in install, mkdir, and mkfifo.

‘
modification-time

’

‘
-m

’ in tar.

‘
multi-volume

’

‘
-M

’ in tar.

‘
name-prefix

’

‘
-a

’ in Bison.

‘
nesting-limit

’

‘
-L

’ in m4.

‘
net-headers

’

‘
-a

’ in shar.

‘
new-file

’

‘
-W

’ in make.

‘
no-builtin-rules

’

‘
-r

’ in make.

‘
no-character-count

’

‘
-w

’ in shar.

‘
no-check-existing

’

‘
-x

’ in shar.

‘
no-common

’

‘
-3

’ in wdiff.

‘
no-create

’

‘
-c

’ in touch.

‘
no-defines

’

‘
-D

’ in etags.

‘
no-deleted

’

‘
-1

’ in wdiff.

‘
no-dereference

’

‘
-d

’ in cp.

‘
no-inserted

’

‘
-2

’ in wdiff.

‘
no-keep-going

’

‘
-S

’ in make.

‘
no-lines

’

‘
-l

’ in Bison.

‘
no-piping

’

‘
-P

’ in shar.

‘
no-prof

’

‘
-e

’ in gprof.

‘
no-regex

’

‘
-R

’ in etags.

‘
no-sort

’

‘
-p

’ in nm.

‘
no-splash

’

Don’t print a startup splash screen.

‘
no-split

’

Used in makeinfo.

‘
no-static

’

‘
-a

’ in gprof.

‘
no-time

’

‘
-E

’ in gprof.

‘
no-timestamp

’

‘
-m

’ in shar.

‘
no-validate

’

Used in makeinfo.

‘
no-wait

’

Used in emacsclient.

‘
no-warn

’

Used in various programs to inhibit warnings.

‘
node

’

‘
-n

’ in info.

‘
nodename

’

‘
-n

’ in uname.

‘
nonmatching

’

‘
-f

’ in cpio.

‘
nstuff

’

‘
-n

’ in objdump.

‘
null

’

‘
-0

’ in xargs.

‘
number

’

‘
-n

’ in cat.

‘
number-nonblank

’

‘
-b

’ in cat.

‘
numeric-sort

’

‘
-n

’ in nm.

‘
numeric-uid-gid

’

‘
-n

’ in cpio and ls.

‘
nx

’

Used in GDB.

‘
old-archive

’

‘
-o

’ in tar.

‘
old-file

’

‘
-o

’ in make.

‘
one-file-system

’

‘
-l

’ in tar, cp, and du.

‘
only-file

’

‘
-o

’ in ptx.

‘
only-prof

’

‘
-f

’ in gprof.

‘
only-time

’

‘
-F

’ in gprof.

‘
options

’

‘
-o

’ in getopt, fdlist, fdmount, fdmountd, and fdumount.

‘
output

’

In various programs, specify the output file name.

‘
output-prefix

’

‘
-o

’ in shar.

‘
override

’

‘
-o

’ in rm.

‘
overwrite

’

‘
-c

’ in unshar.

‘
owner

’

‘
-o

’ in install.

‘
paginate

’

‘
-l

’ in diff.

‘
paragraph-indent

’

Used in makeinfo.

‘
parents

’

‘
-p

’ in mkdir and rmdir.

‘
pass-all

’

‘
-p

’ in ul.

‘
pass-through

’

‘
-p

’ in cpio.

‘
port

’

‘
-P

’ in finger.

‘
portability

’

‘
-c

’ in cpio and tar.

‘
posix

’

Used in gawk.

‘
prefix-builtins

’

‘
-P

’ in m4.

‘
prefix

’

‘
-f

’ in csplit.

‘
preserve

’

Used in tar and cp.

‘
preserve-environment

’

‘
-p

’ in su.

‘
preserve-modification-time

’

‘
-m

’ in cpio.

‘
preserve-order

’

‘
-s

’ in tar.

‘
preserve-permissions

’

‘
-p

’ in tar.

‘
print

’

‘
-l

’ in diff.

‘
print-chars

’

‘
-L

’ in cmp.

‘
print-data-base

’

‘
-p

’ in make.

‘
print-directory

’

‘
-w

’ in make.

‘
print-file-name

’

‘
-o

’ in nm.

‘
print-symdefs

’

‘
-s

’ in nm.

‘
printer

’

‘
-p

’ in wdiff.

‘
prompt

’

‘
-p

’ in ed.

‘
proxy

’

Specify an HTTP proxy.

‘
query-user

’

‘
-X

’ in shar.

‘
question

’

‘
-q

’ in make.

‘
quiet

’

Used in many programs to inhibit the usual output. Every program accepting ‘
–quiet

’ should accept ‘
–silent

’ as a synonym.

‘
quiet-unshar

’

‘
-Q

’ in shar

‘
quote-name

’

‘
-Q

’ in ls.

‘
rcs

’

‘
-n

’ in diff.

‘
re-interval

’

Used in gawk.

‘
read-full-blocks

’

‘
-B

’ in tar.

‘
readnow

’

Used in GDB.

‘
recon

’

‘
-n

’ in make.

‘
record-number

’

‘
-R

’ in tar.

‘
recursive

’

Used in chgrp, chown, cp, ls, diff, and rm.

‘
reference

’

‘
-r

’ in touch.

‘
references

’

‘
-r

’ in ptx.

‘
regex

’

‘
-r

’ in tac and etags.

‘
release

’

‘
-r

’ in uname.

‘
reload-state

’

‘
-R

’ in m4.

‘
relocation

’

‘
-r

’ in objdump.

‘
rename

’

‘
-r

’ in cpio.

‘
replace

’

‘
-i

’ in xargs.

‘
report-identical-files

’

‘
-s

’ in diff.

‘
reset-access-time

’

‘
-a

’ in cpio.

‘
reverse

’

‘
-r

’ in ls and nm.

‘
reversed-ed

’

‘
-f

’ in diff.

‘
right-side-defs

’

‘
-R

’ in ptx.

‘
same-order

’

‘
-s

’ in tar.

‘
same-permissions

’

‘
-p

’ in tar.

‘
save

’

‘
-g

’ in stty.

‘
se

’

Used in GDB.

‘
sentence-regexp

’

‘
-S

’ in ptx.

‘
separate-dirs

’

‘
-S

’ in du.

‘
separator

’

‘
-s

’ in tac.

‘
sequence

’

Used by recode to chose files or pipes for sequencing passes.

‘
shell

’

‘
-s

’ in su.

‘
show-all

’

‘
-A

’ in cat.

‘
show-c-function

’

‘
-p

’ in diff.

‘
show-ends

’

‘
-E

’ in cat.

‘
show-function-line

’

‘
-F

’ in diff.

‘
show-tabs

’

‘
-T

’ in cat.

‘
silent

’

Used in many programs to inhibit the usual output. Every program accepting ‘
–silent

’ should accept ‘
–quiet

’ as a synonym.

‘
size

’

‘
-s

’ in ls.

‘
socket

’

Specify a file descriptor for a network server to use for its socket, instead of opening and binding a new socket. This provides a way to run, in a non-privileged process, a server that normally needs a reserved port number.

‘
sort

’

Used in ls.

‘
source

’

‘
-W source

’ in gawk.

‘
sparse

’

‘
-S

’ in tar.

‘
speed-large-files

’

‘
-H

’ in diff.

‘
split-at

’

‘
-E

’ in unshar.

‘
split-size-limit

’

‘
-L

’ in shar.

‘
squeeze-blank

’

‘
-s

’ in cat.

‘
start-delete

’

‘
-w

’ in wdiff.

‘
start-insert

’

‘
-y

’ in wdiff.

‘
starting-file

’

Used in tar and diff to specify which file within a directory to start processing with.

‘
statistics

’

‘
-s

’ in wdiff.

‘
stdin-file-list

’

‘
-S

’ in shar.

‘
stop

’

‘
-S

’ in make.

‘
strict

’

‘
-s

’ in recode.

‘
strip

’

‘
-s

’ in install.

‘
strip-all

’

‘
-s

’ in strip.

‘
strip-debug

’

‘
-S

’ in strip.

‘
submitter

’

‘
-s

’ in shar.

‘
suffix

’

‘
-S

’ in cp, ln, mv.

‘
suffix-format

’

‘
-b

’ in csplit.

‘
sum

’

‘
-s

’ in gprof.

‘
summarize

’

‘
-s

’ in du.

‘
symbolic

’

‘
-s

’ in ln.

‘
symbols

’

Used in GDB and objdump.

‘
synclines

’

‘
-s

’ in m4.

‘
sysname

’

‘
-s

’ in uname.

‘
tabs

’

‘
-t

’ in expand and unexpand.

‘
tabsize

’

‘
-T

’ in ls.

‘
terminal

’

‘
-T

’ in tput and ul. ‘
-t

’ in wdiff.

‘
text

’

‘
-a

’ in diff.

‘
text-files

’

‘
-T

’ in shar.

‘
time

’

Used in ls and touch.

‘
timeout

’

Specify how long to wait before giving up on some operation.

‘
to-stdout

’

‘
-O

’ in tar.

‘
total

’

‘
-c

’ in du.

‘
touch

’

‘
-t

’ in make, ranlib, and recode.

‘
trace

’

‘
-t

’ in m4.

‘
traditional

’

‘
-t

’ in hello; ‘
-W traditional

’ in gawk; ‘
-G

’ in ed, m4, and ptx.

‘
tty

’

Used in GDB.

‘
typedefs

’

‘
-t

’ in ctags.

‘
typedefs-and-c++

’

‘
-T

’ in ctags.

‘
typeset-mode

’

‘
-t

’ in ptx.

‘
uncompress

’

‘
-z

’ in tar.

‘
unconditional

’

‘
-u

’ in cpio.

‘
undefine

’

‘
-U

’ in m4.

‘
undefined-only

’

‘
-u

’ in nm.

‘
update

’

‘
-u

’ in cp, ctags, mv, tar.

‘
usage

’

Used in gawk; same as ‘
–help

’.

‘
uuencode

’

‘
-B

’ in shar.

‘
vanilla-operation

’

‘
-V

’ in shar.

‘
verbose

’

Print more information about progress. Many programs support this.

‘
verify

’

‘
-W

’ in tar.

‘
version

’

Print the version number.

‘
version-control

’

‘
-V

’ in cp, ln, mv.

‘
vgrind

’

‘
-v

’ in ctags.

‘
volume

’

‘
-V

’ in tar.

‘
what-if

’

‘
-W

’ in make.

‘
whole-size-limit

’

‘
-l

’ in shar.

‘
width

’

‘
-w

’ in ls and ptx.

‘
word-regexp

’

‘
-W

’ in ptx.

‘
writable

’

‘
-T

’ in who.

‘
zeros

’

‘
-z

’ in gprof.

4.10 OID Allocations

The OID (object identifier) 1.3.6.1.4.1.11591 has been assigned to the GNU Project (thanks to Werner Koch). These are used for SNMP, LDAP, X.509 certificates, and so on. The web site http://www.alvestrand.no/objectid has a (voluntary) listing of many OID assignments.

4.11 Memory Usage

Memory analysis tools such as valgrind can be useful, but don’t complicate a program merely to avoid their false alarms. For example, if memory is used until just before a process exits, don’t free it simply to silence such a tool.

5.1 Formatting Your Source Code

It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this:

static char *
concat (char *s1, char *s2)
{
 …
}

or, if you want to use traditional C syntax, format the definition like this:

static char *
concat (s1, s2) /* Name starts in column one here */
 char *s1, *s2;
{ /* Open brace in column one here */
 …
}

The rest of this section gives our recommendations for other aspects of C formatting style, which is also the default style of the indent program in version 1.2 and newer. It corresponds to the options

-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob

Insert extra parentheses so that Emacs will indent the code properly. For example, the following indentation looks nice if you do it by hand,

v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
 + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;

but Emacs would alter it. Adding a set of parentheses produces something that looks equally nice, and which Emacs will preserve:

v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
 + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);

Format do-while statements like this:

do
 {
 a = foo (a);
 }
while (a > 0);

Please use formfeed characters (control-L) to divide the program into pages at logical places (but not within a function). It does not matter just how long the pages are, since they do not have to fit on a printed page. The formfeeds should appear alone on lines by themselves.

5.2 Commenting Your Work

Every ‘
#endif

’ should have a comment, except in the case of short conditionals (just a few lines) that are not nested. The comment should state the condition of the conditional that is ending, including its sense. ‘
#else

’ should have a comment describing the condition and sense of the code that follows. For example:

#ifdef foo
 …
#else /* not foo */
 …
#endif /* not foo */
#ifdef foo
 …
#endif /* foo */

but, by contrast, write the comments this way for a ‘
#ifndef

’:

#ifndef foo
 …
#else /* foo */
 …
#endif /* foo */
#ifndef foo
 …
#endif /* not foo */

5.3 Clean Use of C Constructs

It used to be common practice to use the same local variables (with names like tem) over and over for different values within one function. Instead of doing this, it is better to declare a separate local variable for each distinct purpose, and give it a name which is meaningful. This not only makes programs easier to understand, it also facilitates optimization by good compilers. You can also move the declaration of each local variable into the smallest scope that includes all its uses. This makes the program even cleaner.

Don’t use local variables or parameters that shadow global identifiers. GCC’s ‘
-Wshadow

’ option can detect this problem.

5.4 Naming Variables, Functions, and Files

You might want to make sure that none of the file names would conflict if the files were loaded onto an MS-DOS file system which shortens the names. You can use the programdoschk to test for this.

5.5 Portability between System Types

The easiest way to achieve portability to most Unix-like systems is to use Autoconf. It’s unlikely that your program needs to know more information about the host platform than Autoconf can provide, simply because most of the programs that need such knowledge have already been written.

5.6 Portability between CPUs

Predefined file-size types like off_t are an exception: they are longer than long on many platforms, so code like the above won’t work with them. One way to print anoff_t value portably is to print its digits yourself, one by one.

Don’t assume that the address of an int object is also the address of its least-significant byte. This is false on big-endian machines. Thus, don’t make the following mistake:

int c;
…
while ((c = getchar ()) != EOF)
 write (file_descriptor, &c, 1);

Instead, use unsigned char as follows. (The unsigned is for portability to unusual systems where char is signed and where there is integer overflow checking.)

int c;
while ((c = getchar ()) != EOF)
 {
 unsigned char u = c;
 write (file_descriptor, &u, 1);
 }

5.7 Calling System Functions

Despite the standards, nearly every library function has some sort of portability issue on some system or another. Here are some examples:

open

Names with trailing /’s are mishandled on many platforms.

printf

long double may be unimplemented; floating values Infinity and NaN are often mishandled; output for large precisions may be incorrect.

readlink

May return int instead of ssize_t.

scanf

On Windows, errno is not set on failure.

Gnulib is a big help in this regard. Gnulib provides implementations of standard interfaces on many of the systems that lack them, including portable implementations of enhanced GNU interfaces, thereby making their use portable, and of POSIX-1.2008 interfaces, some of which are missing even on up-to-date GNU systems.

The Gnulib and Autoconf manuals have extensive sections on portability: Introduction in Gnulib and see Portable C and C++ in Autoconf. Please consult them for many more details.

5.8 Internationalization

GNU has a library called GNU gettext that makes it easy to translate the messages in a program into various languages. You should use this library in every program. Use English for the messages as they appear in the program, and let gettext provide the way to translate them into other languages.

Using GNU gettext involves putting a call to the gettext macro around each string that might need translation—like this:

printf (gettext ("Processing file `%s'..."));

This permits GNU gettext to replace the string "Processing file `%s'..." with a translated version.

Once a program uses gettext, please make a point of writing calls to gettext when you add new strings that call for translation.

5.10 Quote Characters

The Gnulib quote and quotearg modules provide a reasonably straightforward way to support locale-specific quote characters, as well as taking care of other issues, such as quoting a filename that itself contains a quote character. See the Gnulib documentation for usage details.

6.1 GNU Manuals

The preferred document format for the GNU system is the Texinfo formatting language. Every GNU package should (ideally) have documentation in Texinfo both for reference and for learners. Texinfo makes it possible to produce a good quality formatted book, using TeX, and to generate an Info file. It is also possible to generate HTML output from Texinfo source. See the Texinfo manual, either the hardcopy, or the on-line version available through info or the Emacs Info subsystem (C-h i).

The manual which discusses a program should certainly document all of the program’s command-line options and all of its commands. It should give examples of their use. But don’t organize the manual as a list of features. Instead, organize it logically, by subtopics. Address the questions that a user will ask when thinking about the job that the program does. Don’t just tell the reader what each feature can do—say what jobs it is good for, and show how to use it for those jobs. Explain what is recommended usage, and what kinds of usage users should avoid.

The Bison manual is a good example of this—please take a look at it to see what we mean. 
To serve as a reference, a manual should have an Index that list all the functions, variables, options, and important concepts that are part of the program. One combined Index should do for a short manual, but sometimes for a complex package it is better to use multiple indices. The Texinfo manual includes advice on preparing good index entries, see Making Index Entries in GNU Texinfo, and see Defining the Entries of an Index in GNU Texinfo. 

Please include an email address in the manual for where to report bugs in the text of the manual.

Please do not use the term “pathname” that is used in Unix documentation; use “file name” (two words) instead. We use the term “path” only for search paths, which are lists of directory names.

Please do not use the term “illegal” to refer to erroneous input to a computer program. Please use “invalid” for this, and reserve the term “illegal” for activities prohibited by law.

Please do not write ‘
()

’ after a function name just to indicate it is a function. foo () is not a function, it is a function call with no arguments.

6.3 Manual Structure Details

Each program documented in the manual should have a node named ‘program Invocation

’ or ‘
Invoking

program’. This node (together with its subnodes, if any) should describe the program’s command line arguments and how to run it (the sort of information people would look for in a man page). Start with an ‘
@example

’ containing a template for all the options and arguments that the program uses.

6.9 Man Pages

Finally, the GNU help2man program (http://www.gnu.org/software/help2man/) is one way to automate generation of a man page, in this case from ‘--help

’ output. This is sufficient in many cases.

7 The Release Process

Making a release is more than just bundling up your source files in a tar file and putting it up for FTP. You should set up your software so that it can be configured to run on a variety of systems. Your Makefile should conform to the GNU standards described below, and your directory layout should also conform to the standards discussed below. Doing so makes it easy to include your package into the larger framework of all GNU software.

7.1 How Configuration Should Work

The description here is the specification of the interface for the configure script in GNU packages. Many packages implement it using GNU Autoconf (see Introduction in Autoconf) and/or GNU Automake (see Introduction in Automake), but you do not have to use these tools. You can implement it any way you like; for instance, by making configure be a wrapper around a completely different configuration system. 

In addition, the ‘
configure

’ script should take options corresponding to most of the standard directory variables (see Directory Variables). Here is the list:

--prefix --exec-prefix --bindir --sbindir --libexecdir --sysconfdir
--sharedstatedir --localstatedir --libdir --includedir --oldincludedir
--datarootdir --datadir --infodir --localedir --mandir --docdir
--htmldir --dvidir --pdfdir --psdir

The configure script should also take an argument which specifies the type of system to build the program for. This argument should look like this:

cpu-company-system

For example, an Athlon-based GNU/Linux system might be ‘
i686-pc-linux-gnu

’.

The configure script needs to be able to decode all plausible alternatives for how to describe a machine. Thus, ‘
athlon-pc-gnu/linux

’ would be a valid alias. There is a shell script called ‘config.sub’ that you can use as a subroutine to validate system types and canonicalize aliases.

The configure script should also take the option ‘--build=

buildtype’, which should be equivalent to a plain buildtype argument. For example, ‘
configure –build=i686-pc-linux-gnu

’ is equivalent to ‘
configure i686-pc-linux-gnu

’. When the build type is not specified by an option or argument, the configure script should normally guess it using the shell script ‘config.guess’.

Other options are permitted to specify in more detail the software or hardware present on the machine, to include or exclude optional parts of the package, or to adjust the name of some tools or arguments to them:

‘
–enable-

feature
[=

parameter
]

’

Configure the package to build and install an optional user-level facility called feature. This allows users to choose which optional features to include. Giving an optional parameter of ‘
no’ should omit feature, if it is built by default.

No ‘
–enable’ option should ever cause one feature to replace another. No ‘
–enable’ option should ever substitute one useful behavior for another useful behavior. The only proper use for ‘
–enable’ is for questions of whether to build part of the program or exclude it.

‘
–with-

package’

The package package will be installed, so configure this package to work with package.

Possible values of package include ‘
gnu-as’ (or ‘
gas’), ‘
gnu-ld’, ‘
gnu-libc

’, ‘
gdb

’, ‘
x

’, and ‘
x-toolkit

’.

Do not use a ‘
–with’ option to specify the file name to use to find certain files. That is outside the scope of what ‘
–with’ options are for.

‘variable
=

value’

Set the value of the variable variable to value. This is used to override the default values of commands or arguments in the build process. For example, the user could issue ‘
configure CFLAGS=-g CXXFLAGS=-g’ to build with debugging information and without the default optimization.

Specifying variables as arguments to configure, like this:

./configure CC=gcc

is preferable to setting them in environment variables:

CC=gcc ./configure

as it helps to recreate the same configuration later with ‘config.status’. However, both methods should be supported.

All configure scripts should accept all of the “detail” options and the variable settings, whether or not they make any difference to the particular package at hand. In particular, they should accept any option that starts with ‘
–with-

’ or ‘
–enable-

’. This is so users will be able to configure an entire GNU source tree at once with a single set of options.

To configure a cross-compiler, cross-assembler, or what have you, you should specify a target different from the host, using the configure option ‘
–target=

targettype’. The syntax for targettype is the same as for the host type. So the command would look like this:

./configure --host=hosttype --target=targettype

The target type normally defaults to the host type. Programs for which cross-operation is not meaningful need not accept the ‘
–target

’ option, because configuring an entire operating system for cross-operation is not a meaningful operation.

7.2 Makefile Conventions

This describes conventions for writing the Makefiles for GNU programs. Using Automake will help you write a Makefile that follows these conventions. For more information on portable Makefiles, see POSIX and Portable Make Programming in Autoconf.

7.2.1 General Conventions for Makefiles

Every Makefile should contain this line:

SHELL = /bin/sh
to avoid trouble on systems where the SHELL variable might be inherited from the environment. (This is never a problem with GNU make.) 

When using GNU make, relying on ‘
VPATH

’ to find the source file will work in the case where there is a single dependency file, since the make automatic variable ‘
$<

’ will represent the source file wherever it is. (Many versions of make set ‘
$<

’ only in implicit rules.) A Makefile target like

foo.o : bar.c
 $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o

should instead be written as

foo.o : bar.c
 $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@

in order to allow ‘
VPATH

’ to work correctly. When the target has multiple dependencies, using an explicit ‘
$(srcdir)

’ is the easiest way to make the rule work well. For example, the target above for ‘foo.1’ is best written as:

foo.1 : foo.man sedscript
 sed -f $(srcdir)/sedscript $(srcdir)/foo.man > $@

7.2.2 Utilities in Makefiles

Write the Makefile commands (and any shell scripts, such as configure) to run under sh (both the traditional Bourne shell and the POSIX shell), not csh. Don’t use any special features of ksh or bash, or POSIX features not widely supported in traditional Bourne sh.

The configure script and the Makefile rules for building and installation should not use any utilities directly except these:

awk cat cmp cp diff echo egrep expr false grep install-info ln ls
mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true

Compression programs such as gzip can be used in the dist rule.

Generally, stick to the widely-supported (usually POSIX-specified) options and features of these programs. For example, don’t use ‘mkdir -p

’, convenient as it may be, because a few systems don’t support it at all and with others, it is not safe for parallel execution. For a list of known incompatibilities, see Portable Shell Programming in Autoconf.

The Makefile rules for building and installation can also use compilers and related programs, but should do so via make variables so that the user can substitute alternatives. Here are some of the programs we mean:

ar bison cc flex install ld ldconfig lex
make makeinfo ranlib texi2dvi yacc

Use the following make variables to run those programs:

$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX)
$(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)

When you use ranlib or ldconfig, you should make sure nothing bad happens if the system does not have the program in question. Arrange to ignore an error from that command, and print a message before the command to tell the user that failure of this command does not mean a problem. (The Autoconf ‘
AC_PROG_RANLIB

’ macro can help with this.)

Additional utilities that can be used via Make variables are:

chgrp chmod chown mknod

7.2.3 Variables for Specifying Commands

Every Makefile should also define the variables INSTALL_PROGRAM and INSTALL_DATA. (The default for INSTALL_PROGRAM should be $(INSTALL); the default for INSTALL_DATA should be ${INSTALL} -m 644.) Then it should use those variables as the commands for actual installation, for executables and non-executables respectively. Minimal use of these variables is as follows:

$(INSTALL_PROGRAM) foo $(bindir)/foo
$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a

However, it is preferable to support a DESTDIR prefix on the target files, as explained in the next section.

7.2.4 DESTDIR: Support for Staged Installs

DESTDIR is a variable prepended to each installed target file, like this:

$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a

The DESTDIR variable is specified by the user on the make command line as an absolute file name. For example:

make DESTDIR=/tmp/stage install

DESTDIR should be supported only in the install* and uninstall* targets, as those are the only targets where it is useful.

7.2.5 Variables for Installation Directories

These first two variables set the root for the installation. All the other installation directories should be subdirectories of one of these two, and nothing should be directly installed into these two directories.

prefix

A prefix used in constructing the default values of the variables listed below. The default value of prefix should be ‘/usr/local’. When building the complete GNU system, the prefix will be empty and ‘/usr’ will be a symbolic link to ‘/’. (If you are using Autoconf, write it as ‘
@prefix@’.)

Running ‘
make install’ with a different value of prefix from the one used to build the program should not recompile the program.

exec_prefix

A prefix used in constructing the default values of some of the variables listed below. The default value of exec_prefix should be $(prefix). (If you are using Autoconf, write it as ‘
@exec_prefix@’.)

Generally, $(exec_prefix) is used for directories that contain machine-specific files (such as executables and subroutine libraries), while $(prefix) is used directly for other directories.

Running ‘
make install’ with a different value of exec_prefix from the one used to build the program should not recompile the program.

Executable programs are installed in one of the following directories.

bindir

The directory for installing executable programs that users can run. This should normally be ‘/usr/local/bin’, but write it as ‘$(exec_prefix)/bin’. (If you are using Autoconf, write it as ‘
@bindir@’.)

sbindir

The directory for installing executable programs that can be run from the shell, but are only generally useful to system administrators. This should normally be ‘/usr/local/sbin’, but write it as ‘$(exec_prefix)/sbin’. (If you are using Autoconf, write it as ‘
@sbindir@’.)

libexecdir

The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write it as ‘
@libexecdir@’.)

The definition of ‘
libexecdir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under ‘$(libexecdir)/package-name/’, possibly within additional subdirectories thereof, such as ‘$(libexecdir)/package-name/machine/version’.

Data files used by the program during its execution are divided into categories in two ways.

• Some files are normally modified by programs; others are never normally modified (though users may edit some of these).
• Some files are architecture-independent and can be shared by all machines at a site; some are architecture-dependent and can be shared only by machines of the same kind and operating system; others may never be shared between two machines.

This makes for six different possibilities. However, we want to discourage the use of architecture-dependent files, aside from object files and libraries. It is much cleaner to make other data files architecture-independent, and it is generally not hard.

Here are the variables Makefiles should use to specify directories to put these various kinds of files in:

‘
datarootdir

’

The root of the directory tree for read-only architecture-independent data files. This should normally be ‘/usr/local/share’, but write it as ‘$(prefix)/share’. (If you are using Autoconf, write it as ‘
@datarootdir@’.) ‘
datadir’’s default value is based on this variable; so are ‘
infodir’, ‘
mandir

’, and others.

‘
datadir

’

The directory for installing idiosyncratic read-only architecture-independent data files for this program. This is usually the same place as ‘
datarootdir’, but we use the two separate variables so that you can move these program-specific files without altering the location for Info files, man pages, etc.

This should normally be ‘/usr/local/share’, but write it as ‘$(datarootdir)’. (If you are using Autoconf, write it as ‘
@datadir@’.)

The definition of ‘
datadir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under ‘$(datadir)/package-name/’.

‘
sysconfdir

’

The directory for installing read-only data files that pertain to a single machine–that is to say, files for configuring a host. Mailer and network configuration files, ‘/etc/passwd’, and so forth belong here. All the files in this directory should be ordinary ASCII text files. This directory should normally be ‘/usr/local/etc’, but write it as ‘$(prefix)/etc’. (If you are using Autoconf, write it as ‘
@sysconfdir@’.)

Do not install executables here in this directory (they probably belong in ‘$(libexecdir)’ or ‘$(sbindir)’). Also do not install files that are modified in the normal course of their use (programs whose purpose is to change the configuration of the system excluded). Those probably belong in ‘$(localstatedir)’.

‘
sharedstatedir

’

The directory for installing architecture-independent data files which the programs modify while they run. This should normally be ‘/usr/local/com’, but write it as ‘$(prefix)/com’. (If you are using Autoconf, write it as ‘
@sharedstatedir@’.)

‘
localstatedir

’

The directory for installing data files which the programs modify while they run, and that pertain to one specific machine. Users should never need to modify files in this directory to configure the package’s operation; put such configuration information in separate files that go in ‘$(datadir)’ or ‘$(sysconfdir)’. ‘$(localstatedir)’ should normally be ‘/usr/local/var’, but write it as ‘$(prefix)/var’. (If you are using Autoconf, write it as ‘
@localstatedir@’.)

These variables specify the directory for installing certain specific types of files, if your program has them. Every GNU package should have Info files, so every program needs ‘
infodir

’, but not all need ‘
libdir

’ or ‘
lispdir

’.

‘
includedir

’

The directory for installing header files to be included by user programs with the C ‘
#include’ preprocessor directive. This should normally be ‘/usr/local/include’, but write it as ‘$(prefix)/include’. (If you are using Autoconf, write it as ‘
@includedir@’.)

Most compilers other than GCC do not look for header files in directory ‘/usr/local/include’. So installing the header files this way is only useful with GCC. Sometimes this is not a problem because some libraries are only really intended to work with GCC. But some libraries are intended to work with other compilers. They should install their header files in two places, one specified by includedir and one specified by oldincludedir.

‘
oldincludedir

’

The directory for installing ‘
#include’ header files for use with compilers other than GCC. This should normally be ‘/usr/include’. (If you are using Autoconf, you can write it as ‘
@oldincludedir@’.)

The Makefile commands should check whether the value of oldincludedir is empty. If it is, they should not try to use it; they should cancel the second installation of the header files.

A package should not replace an existing header in this directory unless the header came from the same package. Thus, if your Foo package provides a header file ‘foo.h’, then it should install the header file in the oldincludedir directory if either (1) there is no ‘foo.h’ there or (2) the ‘foo.h’ that exists came from the Foo package.

To tell whether ‘foo.h’ came from the Foo package, put a magic string in the file—part of a comment—and grep for that string.

‘
docdir

’

The directory for installing documentation files (other than Info) for this package. By default, it should be ‘/usr/local/share/doc/yourpkg’, but it should be written as ‘$(datarootdir)/doc/yourpkg’. (If you are using Autoconf, write it as ‘
@docdir@’.) The yourpkg subdirectory, which may include a version number, prevents collisions among files with common names, such as ‘README’.

‘
infodir

’

The directory for installing the Info files for this package. By default, it should be ‘/usr/local/share/info’, but it should be written as ‘$(datarootdir)/info’. (If you are using Autoconf, write it as ‘
@infodir@’.) infodir is separate from docdir for compatibility with existing practice.

‘
htmldir

’

‘
dvidir

’

‘
pdfdir

’

‘
psdir

’

Directories for installing documentation files in the particular format. They should all be set to $(docdir) by default. (If you are using Autoconf, write them as ‘
@htmldir@’, ‘
@dvidir@’, etc.) Packages which supply several translations of their documentation should install them in ‘
$(htmldir)/’ll, ‘
$(pdfdir)/

’ll, etc. where ll is a locale abbreviation such as ‘
en

’ or ‘
pt_BR

’.

‘
libdir

’

The directory for object files and libraries of object code. Do not install executables here, they probably ought to go in ‘$(libexecdir)’ instead. The value of libdir should normally be ‘/usr/local/lib’, but write it as ‘$(exec_prefix)/lib’. (If you are using Autoconf, write it as ‘
@libdir@’.)

‘
lispdir

’

The directory for installing any Emacs Lisp files in this package. By default, it should be ‘/usr/local/share/emacs/site-lisp’, but it should be written as ‘$(datarootdir)/emacs/site-lisp’.

If you are using Autoconf, write the default as ‘
@lispdir@’. In order to make ‘
@lispdir@’ work, you need the following lines in your ‘configure.in’ file:

lispdir='${datarootdir}/emacs/site-lisp'
AC_SUBST(lispdir)

‘
localedir

’

The directory for installing locale-specific message catalogs for this package. By default, it should be ‘/usr/local/share/locale’, but it should be written as ‘$(datarootdir)/locale’. (If you are using Autoconf, write it as ‘
@localedir@’.) This directory usually has a subdirectory per locale.

Unix-style man pages are installed in one of the following:

‘
mandir

’

The top-level directory for installing the man pages (if any) for this package. It will normally be ‘/usr/local/share/man’, but you should write it as ‘$(datarootdir)/man’. (If you are using Autoconf, write it as ‘
@mandir@’.)

‘
man1dir

’

The directory for installing section 1 man pages. Write it as ‘$(mandir)/man1’.

‘
man2dir

’

The directory for installing section 2 man pages. Write it as ‘$(mandir)/man2’

‘
…

’

Don’t make the primary documentation for any GNU software be a man page. Write a manual in Texinfo instead. Man pages are just for the sake of people running GNU software on Unix, which is a secondary application only.

‘
manext

’

The file name extension for the installed man page. This should contain a period followed by the appropriate digit; it should normally be ‘
.1’.

‘
man1ext

’

The file name extension for installed section 1 man pages.

‘
man2ext

’

The file name extension for installed section 2 man pages.

‘
…

’

Use these names instead of ‘
manext’ if the package needs to install man pages in more than one section of the manual.

And finally, you should set the following variable:

‘
srcdir

’

The directory for the sources being compiled. The value of this variable is normally inserted by the configure shell script. (If you are using Autoconf, use ‘
srcdir = @srcdir@’.)

For example:

# Common prefix for installation directories.
# NOTE: This directory must exist when you start the install.
prefix = /usr/local
datarootdir = $(prefix)/share
datadir = $(datarootdir)
exec_prefix = $(prefix)
# Where to put the executable for the command `gcc'.
bindir = $(exec_prefix)/bin
# Where to put the directories used by the compiler.
libexecdir = $(exec_prefix)/libexec
# Where to put the Info files.
infodir = $(datarootdir)/info

7.2.6 Standard Targets for Users

All GNU programs should have the following targets in their Makefiles:

‘
all

’

Compile the entire program. This should be the default target. This target need not rebuild any documentation files; Info files should normally be included in the distribution, and DVI (and other documentation format) files should be made only when explicitly asked for.

By default, the Make rules should compile and link with ‘
-g’, so that executable programs have debugging symbols. Otherwise, you are essentially helpless in the face of a crash, and it is often far from easy to reproduce with a fresh build.

‘
install

’

Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use. If there is a simple test to verify that a program is properly installed, this target should run that test.

Do not strip executables when installing them. This helps eventual debugging that may be needed later, and nowadays disk space is cheap and dynamic loaders typically ensure debug sections are not loaded during normal execution. Users that need stripped binaries may invoke the install-strip target to do that.

If possible, write the install target rule so that it does not modify anything in the directory where the program was built, provided ‘
make all’ has just been done. This is convenient for building the program under one user name and installing it under another.

The commands should create all the directories in which files are to be installed, if they don’t already exist. This includes the directories specified as the values of the variables prefix and exec_prefix, as well as all subdirectories that are needed. One way to do this is by means of an installdirs target as described below.

Use ‘
–’ before any command for installing a man page, so that make will ignore any errors. This is in case there are systems that don’t have the Unix man page documentation system installed.

The way to install Info files is to copy them into ‘$(infodir)’ with $(INSTALL_DATA) (see Command Variables), and then run the install-info program if it is present. install-info is a program that edits the Info ‘dir’ file to add or update the menu entry for the given Info file; it is part of the Texinfo package.

Here is a sample rule to install an Info file that also tries to handle some additional situations, such as install-info not being present.

do-install-info: foo.info installdirs
 $(NORMAL_INSTALL)
# Prefer an info file in . to one in srcdir.
 if test -f foo.info; then d=.; \
 else d="$(srcdir)"; fi; \
 $(INSTALL_DATA) $$d/foo.info \
 "$(DESTDIR)$(infodir)/foo.info"
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# Use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
 $(POST_INSTALL)
 if $(SHELL) -c 'install-info --version' \
 >/dev/null 2>&1; then \
 install-info --dir-file="$(DESTDIR)$(infodir)/dir" \
 "$(DESTDIR)$(infodir)/foo.info"; \
 else true; fi

When writing the install target, you must classify all the commands into three categories: normal ones, pre-installation commands and post-installation commands. See Install Command Categories.

‘
install-html

’

‘
install-dvi

’

‘
install-pdf

’

‘
install-ps

’

These targets install documentation in formats other than Info; they’re intended to be called explicitly by the person installing the package, if that format is desired. GNU prefers Info files, so these must be installed by the install target.

When you have many documentation files to install, we recommend that you avoid collisions and clutter by arranging for these targets to install in subdirectories of the appropriate installation directory, such as htmldir. As one example, if your package has multiple manuals, and you wish to install HTML documentation with many files (such as the “split” mode output by makeinfo --html), you’ll certainly want to use subdirectories, or two nodes with the same name in different manuals will overwrite each other.

Please make these install-format targets invoke the commands for the format target, for example, by making format a dependency.

‘
uninstall

’

Delete all the installed files—the copies that the ‘
install’ and ‘
install-*’ targets create.

This rule should not modify the directories where compilation is done, only the directories where files are installed.

The uninstallation commands are divided into three categories, just like the installation commands. See Install Command Categories.

‘
install-strip

’

Like install, but strip the executable files while installing them. In simple cases, this target can use the install target in a simple way:

install-strip:
 $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
 install

But if the package installs scripts as well as real executables, the install-strip target can’t just refer to the install target; it has to strip the executables but not the scripts.

install-strip should not strip the executables in the build directory which are being copied for installation. It should only strip the copies that are installed.

Normally we do not recommend stripping an executable unless you are sure the program has no bugs. However, it can be reasonable to install a stripped executable for actual execution while saving the unstripped executable elsewhere in case there is a bug.

‘
clean

’

Delete all files in the current directory that are normally created by building the program. Also delete files in other directories if they are created by this makefile. However, don’t delete the files that record the configuration. Also preserve files that could be made by building, but normally aren’t because the distribution comes with them. There is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway.

Delete ‘.dvi’ files here if they are not part of the distribution.

‘
distclean

’

Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program. If you have unpacked the source and built the program without creating any other files, ‘
make distclean’ should leave only the files that were in the distribution. However, there is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway.

‘
mostlyclean

’

Like ‘
clean’, but may refrain from deleting a few files that people normally don’t want to recompile. For example, the ‘
mostlyclean’ target for GCC does not delete ‘libgcc.a’, because recompiling it is rarely necessary and takes a lot of time.

‘
maintainer-clean

’

Delete almost everything that can be reconstructed with this Makefile. This typically includes everything deleted by distclean, plus more: C source files produced by Bison, tags tables, Info files, and so on.

The reason we say “almost everything” is that running the command ‘
make maintainer-clean’ should not delete ‘configure’ even if ‘configure’ can be remade using a rule in the Makefile. More generally, ‘
make maintainer-clean’ should not delete anything that needs to exist in order to run ‘configure’ and then begin to build the program. Also, there is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway. These are the only exceptions; maintainer-clean should delete everything else that can be rebuilt.

The ‘
maintainer-clean’ target is intended to be used by a maintainer of the package, not by ordinary users. You may need special tools to reconstruct some of the files that ‘
make maintainer-clean’ deletes. Since these files are normally included in the distribution, we don’t take care to make them easy to reconstruct. If you find you need to unpack the full distribution again, don’t blame us.

To help make users aware of this, the commands for the special maintainer-clean target should start with these two:

@echo 'This command is intended for maintainers to use; it'
@echo 'deletes files that may need special tools to rebuild.'

‘
TAGS

’

Update a tags table for this program.

‘
info

’

Generate any Info files needed. The best way to write the rules is as follows:

info: foo.info

foo.info: foo.texi chap1.texi chap2.texi
 $(MAKEINFO) $(srcdir)/foo.texi

You must define the variable MAKEINFO in the Makefile. It should run the makeinfo program, which is part of the Texinfo distribution.

Normally a GNU distribution comes with Info files, and that means the Info files are present in the source directory. Therefore, the Make rule for an info file should update it in the source directory. When users build the package, ordinarily Make will not update the Info files because they will already be up to date.

‘
dvi

’

‘
html

’

‘
pdf

’

‘
ps

’

Generate documentation files in the given format. These targets should always exist, but any or all can be a no-op if the given output format cannot be generated. These targets should not be dependencies of the all target; the user must manually invoke them.

Here’s an example rule for generating DVI files from Texinfo:

dvi: foo.dvi

foo.dvi: foo.texi chap1.texi chap2.texi
 $(TEXI2DVI) $(srcdir)/foo.texi

You must define the variable TEXI2DVI in the Makefile. It should run the program texi2dvi, which is part of the Texinfo distribution. (texi2dvi uses TeX to do the real work of formatting. TeX is not distributed with Texinfo.) Alternatively, write only the dependencies, and allow GNU make to provide the command.

Here’s another example, this one for generating HTML from Texinfo:

html: foo.html

foo.html: foo.texi chap1.texi chap2.texi
 $(TEXI2HTML) $(srcdir)/foo.texi

Again, you would define the variable TEXI2HTML in the Makefile; for example, it might run makeinfo --no-split --html (makeinfo is part of the Texinfo distribution).

‘
dist

’

Create a distribution tar file for this program. The tar file should be set up so that the file names in the tar file start with a subdirectory name which is the name of the package it is a distribution for. This name can include the version number.

For example, the distribution tar file of GCC version 1.40 unpacks into a subdirectory named ‘gcc-1.40’.

The easiest way to do this is to create a subdirectory appropriately named, use ln or cp to install the proper files in it, and then tar that subdirectory.

Compress the tar file with gzip. For example, the actual distribution file for GCC version 1.40 is called ‘gcc-1.40.tar.gz’. It is ok to support other free compression formats as well.

The dist target should explicitly depend on all non-source files that are in the distribution, to make sure they are up to date in the distribution. See Making Releases.

‘
check

’

Perform self-tests (if any). The user must build the program before running the tests, but need not install the program; you should write the self-tests so that they work when the program is built but not installed.

The following targets are suggested as conventional names, for programs in which they are useful.

installcheck

Perform installation tests (if any). The user must build and install the program before running the tests. You should not assume that ‘$(bindir)’ is in the search path.

installdirs

It’s useful to add a target named ‘
installdirs’ to create the directories where files are installed, and their parent directories. There is a script called ‘mkinstalldirs’ which is convenient for this; you can find it in the Gnulib package. You can use a rule like this:

# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
 $(srcdir)/mkinstalldirs $(bindir) $(datadir) \
 $(libdir) $(infodir) \
 $(mandir)

or, if you wish to support DESTDIR (strongly encouraged),

# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
 $(srcdir)/mkinstalldirs \
 $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
 $(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
 $(DESTDIR)$(mandir)

This rule should not modify the directories where compilation is done. It should do nothing but create installation directories.

7.2.6 Standard Targets for Users

All GNU programs should have the following targets in their Makefiles:

‘
all

’

Compile the entire program. This should be the default target. This target need not rebuild any documentation files; Info files should normally be included in the distribution, and DVI (and other documentation format) files should be made only when explicitly asked for.

By default, the Make rules should compile and link with ‘
-g’, so that executable programs have debugging symbols. Otherwise, you are essentially helpless in the face of a crash, and it is often far from easy to reproduce with a fresh build.

‘
install

’

Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use. If there is a simple test to verify that a program is properly installed, this target should run that test.

Do not strip executables when installing them. This helps eventual debugging that may be needed later, and nowadays disk space is cheap and dynamic loaders typically ensure debug sections are not loaded during normal execution. Users that need stripped binaries may invoke the install-strip target to do that.

If possible, write the install target rule so that it does not modify anything in the directory where the program was built, provided ‘
make all’ has just been done. This is convenient for building the program under one user name and installing it under another.

The commands should create all the directories in which files are to be installed, if they don’t already exist. This includes the directories specified as the values of the variables prefix and exec_prefix, as well as all subdirectories that are needed. One way to do this is by means of an installdirs target as described below.

Use ‘
–’ before any command for installing a man page, so that make will ignore any errors. This is in case there are systems that don’t have the Unix man page documentation system installed.

The way to install Info files is to copy them into ‘$(infodir)’ with $(INSTALL_DATA) (see Command Variables), and then run the install-info program if it is present. install-info is a program that edits the Info ‘dir’ file to add or update the menu entry for the given Info file; it is part of the Texinfo package.

Here is a sample rule to install an Info file that also tries to handle some additional situations, such as install-info not being present.

do-install-info: foo.info installdirs
 $(NORMAL_INSTALL)
# Prefer an info file in . to one in srcdir.
 if test -f foo.info; then d=.; \
 else d="$(srcdir)"; fi; \
 $(INSTALL_DATA) $$d/foo.info \
 "$(DESTDIR)$(infodir)/foo.info"
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# Use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
 $(POST_INSTALL)
 if $(SHELL) -c 'install-info --version' \
 >/dev/null 2>&1; then \
 install-info --dir-file="$(DESTDIR)$(infodir)/dir" \
 "$(DESTDIR)$(infodir)/foo.info"; \
 else true; fi

When writing the install target, you must classify all the commands into three categories: normal ones, pre-installation commands and post-installation commands. See Install Command Categories.

‘
install-html

’

‘
install-dvi

’

‘
install-pdf

’

‘
install-ps

’

These targets install documentation in formats other than Info; they’re intended to be called explicitly by the person installing the package, if that format is desired. GNU prefers Info files, so these must be installed by the install target.

When you have many documentation files to install, we recommend that you avoid collisions and clutter by arranging for these targets to install in subdirectories of the appropriate installation directory, such as htmldir. As one example, if your package has multiple manuals, and you wish to install HTML documentation with many files (such as the “split” mode output by makeinfo --html), you’ll certainly want to use subdirectories, or two nodes with the same name in different manuals will overwrite each other.

Please make these install-format targets invoke the commands for the format target, for example, by making format a dependency.

‘
uninstall

’

Delete all the installed files—the copies that the ‘
install’ and ‘
install-*’ targets create.

This rule should not modify the directories where compilation is done, only the directories where files are installed.

The uninstallation commands are divided into three categories, just like the installation commands. See Install Command Categories.

‘
install-strip

’

Like install, but strip the executable files while installing them. In simple cases, this target can use the install target in a simple way:

install-strip:
 $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
 install

But if the package installs scripts as well as real executables, the install-strip target can’t just refer to the install target; it has to strip the executables but not the scripts.

install-strip should not strip the executables in the build directory which are being copied for installation. It should only strip the copies that are installed.

Normally we do not recommend stripping an executable unless you are sure the program has no bugs. However, it can be reasonable to install a stripped executable for actual execution while saving the unstripped executable elsewhere in case there is a bug.

‘
clean

’

Delete all files in the current directory that are normally created by building the program. Also delete files in other directories if they are created by this makefile. However, don’t delete the files that record the configuration. Also preserve files that could be made by building, but normally aren’t because the distribution comes with them. There is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway.

Delete ‘.dvi’ files here if they are not part of the distribution.

‘
distclean

’

Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program. If you have unpacked the source and built the program without creating any other files, ‘
make distclean’ should leave only the files that were in the distribution. However, there is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway.

‘
mostlyclean

’

Like ‘
clean’, but may refrain from deleting a few files that people normally don’t want to recompile. For example, the ‘
mostlyclean’ target for GCC does not delete ‘libgcc.a’, because recompiling it is rarely necessary and takes a lot of time.

‘
maintainer-clean

’

Delete almost everything that can be reconstructed with this Makefile. This typically includes everything deleted by distclean, plus more: C source files produced by Bison, tags tables, Info files, and so on.

The reason we say “almost everything” is that running the command ‘
make maintainer-clean’ should not delete ‘configure’ even if ‘configure’ can be remade using a rule in the Makefile. More generally, ‘
make maintainer-clean’ should not delete anything that needs to exist in order to run ‘configure’ and then begin to build the program. Also, there is no need to delete parent directories that were created with ‘
mkdir -p’, since they could have existed anyway. These are the only exceptions; maintainer-clean should delete everything else that can be rebuilt.

The ‘
maintainer-clean’ target is intended to be used by a maintainer of the package, not by ordinary users. You may need special tools to reconstruct some of the files that ‘
make maintainer-clean’ deletes. Since these files are normally included in the distribution, we don’t take care to make them easy to reconstruct. If you find you need to unpack the full distribution again, don’t blame us.

To help make users aware of this, the commands for the special maintainer-clean target should start with these two:

@echo 'This command is intended for maintainers to use; it'
@echo 'deletes files that may need special tools to rebuild.'

‘
TAGS

’

Update a tags table for this program.

‘
info

’

Generate any Info files needed. The best way to write the rules is as follows:

info: foo.info

foo.info: foo.texi chap1.texi chap2.texi
 $(MAKEINFO) $(srcdir)/foo.texi

You must define the variable MAKEINFO in the Makefile. It should run the makeinfo program, which is part of the Texinfo distribution.

Normally a GNU distribution comes with Info files, and that means the Info files are present in the source directory. Therefore, the Make rule for an info file should update it in the source directory. When users build the package, ordinarily Make will not update the Info files because they will already be up to date.

‘
dvi

’

‘
html

’

‘
pdf

’

‘
ps

’

Generate documentation files in the given format. These targets should always exist, but any or all can be a no-op if the given output format cannot be generated. These targets should not be dependencies of the all target; the user must manually invoke them.

Here’s an example rule for generating DVI files from Texinfo:

dvi: foo.dvi

foo.dvi: foo.texi chap1.texi chap2.texi
 $(TEXI2DVI) $(srcdir)/foo.texi

You must define the variable TEXI2DVI in the Makefile. It should run the program texi2dvi, which is part of the Texinfo distribution. (texi2dvi uses TeX to do the real work of formatting. TeX is not distributed with Texinfo.) Alternatively, write only the dependencies, and allow GNU make to provide the command.

Here’s another example, this one for generating HTML from Texinfo:

html: foo.html

foo.html: foo.texi chap1.texi chap2.texi
 $(TEXI2HTML) $(srcdir)/foo.texi

Again, you would define the variable TEXI2HTML in the Makefile; for example, it might run makeinfo --no-split --html (makeinfo is part of the Texinfo distribution).

‘
dist

’

Create a distribution tar file for this program. The tar file should be set up so that the file names in the tar file start with a subdirectory name which is the name of the package it is a distribution for. This name can include the version number.

For example, the distribution tar file of GCC version 1.40 unpacks into a subdirectory named ‘gcc-1.40’.

The easiest way to do this is to create a subdirectory appropriately named, use ln or cp to install the proper files in it, and then tar that subdirectory.

Compress the tar file with gzip. For example, the actual distribution file for GCC version 1.40 is called ‘gcc-1.40.tar.gz’. It is ok to support other free compression formats as well.

The dist target should explicitly depend on all non-source files that are in the distribution, to make sure they are up to date in the distribution. See Making Releases.

‘
check

’

Perform self-tests (if any). The user must build the program before running the tests, but need not install the program; you should write the self-tests so that they work when the program is built but not installed.

The following targets are suggested as conventional names, for programs in which they are useful.

installcheck

Perform installation tests (if any). The user must build and install the program before running the tests. You should not assume that ‘$(bindir)’ is in the search path.

installdirs

It’s useful to add a target named ‘
installdirs’ to create the directories where files are installed, and their parent directories. There is a script called ‘mkinstalldirs’ which is convenient for this; you can find it in the Gnulib package. You can use a rule like this:

# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
 $(srcdir)/mkinstalldirs $(bindir) $(datadir) \
 $(libdir) $(infodir) \
 $(mandir)

or, if you wish to support DESTDIR (strongly encouraged),

# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
 $(srcdir)/mkinstalldirs \
 $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
 $(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
 $(DESTDIR)$(mandir)

This rule should not modify the directories where compilation is done. It should do nothing but create installation directories.

7.2.7 Install Command Categories

When writing the install target, you must classify all the commands into three categories: normal ones, pre-installation commands and post-installation commands.

Normal commands move files into their proper places, and set their modes. They may not alter any files except the ones that come entirely from the package they belong to.

Pre-installation and post-installation commands may alter other files; in particular, they can edit global configuration files or data bases.

Pre-installation commands are typically executed before the normal commands, and post-installation commands are typically run after the normal commands.

The most common use for a post-installation command is to run install-info. This cannot be done with a normal command, since it alters a file (the Info directory) which does not come entirely and solely from the package being installed. It is a post-installation command because it needs to be done after the normal command which installs the package’s Info files.

Most programs don’t need any pre-installation commands, but we have the feature just in case it is needed.

To classify the commands in the install rule into these three categories, insert category lines among them. A category line specifies the category for the commands that follow.

A category line consists of a tab and a reference to a special Make variable, plus an optional comment at the end. There are three variables you can use, one for each category; the variable name specifies the category. Category lines are no-ops in ordinary execution because these three Make variables are normally undefined (and you should not define them in the makefile).

Here are the three possible category lines, each with a comment that explains what it means:

 $(PRE_INSTALL) # Pre-install commands follow.
 $(POST_INSTALL) # Post-install commands follow.
 $(NORMAL_INSTALL) # Normal commands follow.

If you don’t use a category line at the beginning of the install rule, all the commands are classified as normal until the first category line. If you don’t use any category lines, all the commands are classified as normal.

These are the category lines for uninstall:

 $(PRE_UNINSTALL) # Pre-uninstall commands follow.
 $(POST_UNINSTALL) # Post-uninstall commands follow.
 $(NORMAL_UNINSTALL) # Normal commands follow.

Typically, a pre-uninstall command would be used for deleting entries from the Info directory.

If the install or uninstall target has any dependencies which act as subroutines of installation, then you should start each dependency’s commands with a category line, and start the main target’s commands with a category line also. This way, you can ensure that each command is placed in the right category regardless of which of the dependencies actually run.

Pre-installation and post-installation commands should not run any programs except for these:

[ basename bash cat chgrp chmod chown cmp cp dd diff echo
egrep expand expr false fgrep find getopt grep gunzip gzip
hostname install install-info kill ldconfig ln ls md5sum
mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
test touch true uname xargs yes

The reason for distinguishing the commands in this way is for the sake of making binary packages. Typically a binary package contains all the executables and other files that need to be installed, and has its own method of installing them—so it does not need to run the normal installation commands. But installing the binary package does need to execute the pre-installation and post-installation commands.

Programs to build binary packages work by extracting the pre-installation and post-installation commands. Here is one way of extracting the pre-installation commands (the ‘
-s

’ option to make is needed to silence messages about entering subdirectories):

make -s -n install -o all \
 PRE_INSTALL=pre-install \
 POST_INSTALL=post-install \
 NORMAL_INSTALL=normal-install \
 | gawk -f pre-install.awk

where the file ‘pre-install.awk’ could contain this:

$0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0}
on {print $0}
$0 ~ /^pre-install[ \t]*$/ {on = 1}

7.3 Making Releases

You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers, but it is very unlikely that you really need them.

Package the distribution of Foo version 69.96 up in a gzipped tar file with the name ‘foo-69.96.tar.gz’. It should unpack into a subdirectory named ‘foo-69.96’.

8 References to Non-Free Software and Documentation

A GNU program should not recommend, promote, or grant legitimacy to the use of any non-free program. Proprietary software is a social and ethical problem, and our aim is to put an end to that problem. We can’t stop some people from writing proprietary programs, or stop other people from using them, but we can and should refuse to advertise them to new potential customers, or to give the public the idea that their existence is ethical.

The GNU definition of free software is found on the GNU web site at http://www.gnu.org/philosophy/free-sw.html, and the definition of free documentation is found at http://www.gnu.org/philosophy/free-doc.html. The terms “free” and “non-free”, used in this document, refer to those definitions.

A list of important licenses and whether they qualify as free is in http://www.gnu.org/licenses/license-list.html. If it is not clear whether a license qualifies as free, please ask the GNU Project by writing to licensing@gnu.org. We will answer, and if the license is an important one, we will add it to the list.