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_t
is 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 ofssize_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 theSHELL
variable might be inherited from the environment. (This is never a problem with GNUmake
.)
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 ofprefix
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 ofexec_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 byoldincludedir
. - ‘
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 fromdocdir
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
andexec_prefix
, as well as all subdirectories that are needed. One way to do this is by means of aninstalldirs
target as described below. - Use ‘
–’ before any command for installing a man page, so thatmake
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 theinstall-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 bymakeinfo --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 theinstall
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 theinstall
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 themakeinfo
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 programtexi2dvi
, 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 GNUmake
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 runmakeinfo --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
orcp
to install the proper files in it, and thentar
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
andexec_prefix
, as well as all subdirectories that are needed. One way to do this is by means of aninstalldirs
target as described below. - Use ‘
–’ before any command for installing a man page, so thatmake
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 theinstall-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 bymakeinfo --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 theinstall
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 theinstall
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 themakeinfo
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 programtexi2dvi
, 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 GNUmake
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 runmakeinfo --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
orcp
to install the proper files in it, and thentar
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.