diff options
Diffstat (limited to 'binutils-2.24/etc/make-stds.texi')
| -rw-r--r-- | binutils-2.24/etc/make-stds.texi | 1135 |
1 files changed, 0 insertions, 1135 deletions
diff --git a/binutils-2.24/etc/make-stds.texi b/binutils-2.24/etc/make-stds.texi deleted file mode 100644 index 91a1ed03..00000000 --- a/binutils-2.24/etc/make-stds.texi +++ /dev/null @@ -1,1135 +0,0 @@ -@comment This file is included by both standards.texi and make.texinfo. -@comment It was broken out of standards.texi on 1/6/93 by roland. - -@node Makefile Conventions -@chapter Makefile Conventions -@comment standards.texi does not print an index, but make.texinfo does. -@cindex makefile, conventions for -@cindex conventions for makefiles -@cindex standards for makefiles - -@c Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 2000, 2001, -@c 2004, 2005, 2006 Free Software Foundation, Inc. - -@c Permission is granted to copy, distribute and/or modify this document -@c under the terms of the GNU Free Documentation License, Version 1.2 -@c or any later version published by the Free Software Foundation; -@c with no Invariant Sections, with no -@c Front-Cover Texts, and with no Back-Cover Texts. -@c A copy of the license is included in the section entitled ``GNU -@c Free Documentation License''. - -This -@ifinfo -node -@end ifinfo -@iftex -@ifset CODESTD -section -@end ifset -@ifclear CODESTD -chapter -@end ifclear -@end iftex -describes conventions for writing the Makefiles for GNU programs. -Using Automake will help you write a Makefile that follows these -conventions. - -@menu -* Makefile Basics:: General conventions for Makefiles. -* Utilities in Makefiles:: Utilities to be used in Makefiles. -* Command Variables:: Variables for specifying commands. -* DESTDIR:: Supporting staged installs. -* Directory Variables:: Variables for installation directories. -* Standard Targets:: Standard targets for users. -* Install Command Categories:: Three categories of commands in the `install' - rule: normal, pre-install and post-install. -@end menu - -@node Makefile Basics -@section General Conventions for Makefiles - -Every Makefile should contain this line: - -@example -SHELL = /bin/sh -@end example - -@noindent -to avoid trouble on systems where the @code{SHELL} variable might be -inherited from the environment. (This is never a problem with GNU -@code{make}.) - -Different @code{make} programs have incompatible suffix lists and -implicit rules, and this sometimes creates confusion or misbehavior. So -it is a good idea to set the suffix list explicitly using only the -suffixes you need in the particular Makefile, like this: - -@example -.SUFFIXES: -.SUFFIXES: .c .o -@end example - -@noindent -The first line clears out the suffix list, the second introduces all -suffixes which may be subject to implicit rules in this Makefile. - -Don't assume that @file{.} is in the path for command execution. When -you need to run programs that are a part of your package during the -make, please make sure that it uses @file{./} if the program is built as -part of the make or @file{$(srcdir)/} if the file is an unchanging part -of the source code. Without one of these prefixes, the current search -path is used. - -The distinction between @file{./} (the @dfn{build directory}) and -@file{$(srcdir)/} (the @dfn{source directory}) is important because -users can build in a separate directory using the @samp{--srcdir} option -to @file{configure}. A rule of the form: - -@smallexample -foo.1 : foo.man sedscript - sed -e sedscript foo.man > foo.1 -@end smallexample - -@noindent -will fail when the build directory is not the source directory, because -@file{foo.man} and @file{sedscript} are in the source directory. - -When using GNU @code{make}, relying on @samp{VPATH} to find the source -file will work in the case where there is a single dependency file, -since the @code{make} automatic variable @samp{$<} will represent the -source file wherever it is. (Many versions of @code{make} set @samp{$<} -only in implicit rules.) A Makefile target like - -@smallexample -foo.o : bar.c - $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o -@end smallexample - -@noindent -should instead be written as - -@smallexample -foo.o : bar.c - $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@@ -@end smallexample - -@noindent -in order to allow @samp{VPATH} to work correctly. When the target has -multiple dependencies, using an explicit @samp{$(srcdir)} is the easiest -way to make the rule work well. For example, the target above for -@file{foo.1} is best written as: - -@smallexample -foo.1 : foo.man sedscript - sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@@ -@end smallexample - -GNU distributions usually contain some files which are not source -files---for example, Info files, and the output from Autoconf, Automake, -Bison or Flex. Since these files normally appear in the source -directory, they should always appear in the source directory, not in the -build directory. So Makefile rules to update them should put the -updated files in the source directory. - -However, if a file does not appear in the distribution, then the -Makefile should not put it in the source directory, because building a -program in ordinary circumstances should not modify the source directory -in any way. - -Try to make the build and installation targets, at least (and all their -subtargets) work correctly with a parallel @code{make}. - -@node Utilities in Makefiles -@section Utilities in Makefiles - -Write the Makefile commands (and any shell scripts, such as -@code{configure}) to run in @code{sh}, not in @code{csh}. Don't use any -special features of @code{ksh} or @code{bash}. - -The @code{configure} script and the Makefile rules for building and -installation should not use any utilities directly except these: - -@c dd find -@c gunzip gzip md5sum -@c mkfifo mknod tee uname - -@example -cat cmp cp diff echo egrep expr false grep install-info -ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true -@end example - -The compression program @code{gzip} can be used in the @code{dist} rule. - -Stick to the generally supported options for these programs. For -example, don't use @samp{mkdir -p}, convenient as it may be, because -most systems don't support it. - -It is a good idea to avoid creating symbolic links in makefiles, since a -few systems don't support them. - -The Makefile rules for building and installation can also use compilers -and related programs, but should do so via @code{make} variables so that the -user can substitute alternatives. Here are some of the programs we -mean: - -@example -ar bison cc flex install ld ldconfig lex -make makeinfo ranlib texi2dvi yacc -@end example - -Use the following @code{make} variables to run those programs: - -@example -$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) -$(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC) -@end example - -When you use @code{ranlib} or @code{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 @samp{AC_PROG_RANLIB} macro can help with -this.) - -If you use symbolic links, you should implement a fallback for systems -that don't have symbolic links. - -Additional utilities that can be used via Make variables are: - -@example -chgrp chmod chown mknod -@end example - -It is ok to use other utilities in Makefile portions (or scripts) -intended only for particular systems where you know those utilities -exist. - -@node Command Variables -@section Variables for Specifying Commands - -Makefiles should provide variables for overriding certain commands, options, -and so on. - -In particular, you should run most utility programs via variables. -Thus, if you use Bison, have a variable named @code{BISON} whose default -value is set with @samp{BISON = bison}, and refer to it with -@code{$(BISON)} whenever you need to use Bison. - -File management utilities such as @code{ln}, @code{rm}, @code{mv}, and -so on, need not be referred to through variables in this way, since users -don't need to replace them with other programs. - -Each program-name variable should come with an options variable that is -used to supply options to the program. Append @samp{FLAGS} to the -program-name variable name to get the options variable name---for -example, @code{BISONFLAGS}. (The names @code{CFLAGS} for the C -compiler, @code{YFLAGS} for yacc, and @code{LFLAGS} for lex, are -exceptions to this rule, but we keep them because they are standard.) -Use @code{CPPFLAGS} in any compilation command that runs the -preprocessor, and use @code{LDFLAGS} in any compilation command that -does linking as well as in any direct use of @code{ld}. - -If there are C compiler options that @emph{must} be used for proper -compilation of certain files, do not include them in @code{CFLAGS}. -Users expect to be able to specify @code{CFLAGS} freely themselves. -Instead, arrange to pass the necessary options to the C compiler -independently of @code{CFLAGS}, by writing them explicitly in the -compilation commands or by defining an implicit rule, like this: - -@smallexample -CFLAGS = -g -ALL_CFLAGS = -I. $(CFLAGS) -.c.o: - $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $< -@end smallexample - -Do include the @samp{-g} option in @code{CFLAGS}, because that is not -@emph{required} for proper compilation. You can consider it a default -that is only recommended. If the package is set up so that it is -compiled with GCC by default, then you might as well include @samp{-O} -in the default value of @code{CFLAGS} as well. - -Put @code{CFLAGS} last in the compilation command, after other variables -containing compiler options, so the user can use @code{CFLAGS} to -override the others. - -@code{CFLAGS} should be used in every invocation of the C compiler, -both those which do compilation and those which do linking. - -Every Makefile should define the variable @code{INSTALL}, which is the -basic command for installing a file into the system. - -Every Makefile should also define the variables @code{INSTALL_PROGRAM} -and @code{INSTALL_DATA}. (The default for @code{INSTALL_PROGRAM} should -be @code{$(INSTALL)}; the default for @code{INSTALL_DATA} should be -@code{$@{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: - -@example -$(INSTALL_PROGRAM) foo $(bindir)/foo -$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a -@end example - -However, it is preferable to support a @code{DESTDIR} prefix on the -target files, as explained in the next section. - -@noindent -Always use a file name, not a directory name, as the second argument of -the installation commands. Use a separate command for each file to be -installed. - - -@node DESTDIR -@section @code{DESTDIR}: support for staged installs - -@vindex DESTDIR -@cindex staged installs -@cindex installations, staged - -@code{DESTDIR} is a variable prepended to each installed target file, -like this: - -@example -$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo -$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a -@end example - -The @code{DESTDIR} variable is specified by the user on the @code{make} -command line. For example: - -@example -make DESTDIR=/tmp/stage install -@end example - -@noindent -@code{DESTDIR} should be supported only in the @code{install*} and -@code{uninstall*} targets, as those are the only targets where it is -useful. - -If your installation step would normally install -@file{/usr/local/bin/foo} and @file{/usr/local/lib/libfoo.a}, then an -installation invoked as in the example above would install -@file{/tmp/stage/usr/local/bin/foo} and -@file{/tmp/stage/usr/local/lib/libfoo.a} instead. - -Prepending the variable @code{DESTDIR} to each target in this way -provides for @dfn{staged installs}, where the installed files are not -placed directly into their expected location but are instead copied -into a temporary location (@code{DESTDIR}). However, installed files -maintain their relative directory structure and any embedded file names -will not be modified. - -You should not set the value of @code{DESTDIR} in your @file{Makefile} -at all; then the files are installed into their expected locations by -default. Also, specifying @code{DESTDIR} should not change the -operation of the software in any way, so its value should not be -included in any file contents. - -@code{DESTDIR} support is commonly used in package creation. It is -also helpful to users who want to understand what a given package will -install where, and to allow users who don't normally have permissions -to install into protected areas to build and install before gaining -those permissions. Finally, it can be useful with tools such as -@code{stow}, where code is installed in one place but made to appear -to be installed somewhere else using symbolic links or special mount -operations. So, we strongly recommend GNU packages support -@code{DESTDIR}, though it is not an absolute requirement. - - -@node Directory Variables -@section Variables for Installation Directories - -Installation directories should always be named by variables, so it is -easy to install in a nonstandard place. The standard names for these -variables and the values they should have in GNU packages are -described below. They are based on a standard file system layout; -variants of it are used in GNU/Linux and other modern operating -systems. - -Installers are expected to override these values when calling -@command{make} (e.g., @kbd{make prefix=/usr install} or -@command{configure} (e.g., @kbd{configure --prefix=/usr}). GNU -packages should not try to guess which value should be appropriate for -these variables on the system they are being installed onto: use the -default settings specified here so that all GNU packages behave -identically, allowing the installer to achieve any desired layout. - -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. - -@table @code -@item prefix -@vindex prefix -A prefix used in constructing the default values of the variables listed -below. The default value of @code{prefix} should be @file{/usr/local}. -When building the complete GNU system, the prefix will be empty and -@file{/usr} will be a symbolic link to @file{/}. -(If you are using Autoconf, write it as @samp{@@prefix@@}.) - -Running @samp{make install} with a different value of @code{prefix} from -the one used to build the program should @emph{not} recompile the -program. - -@item exec_prefix -@vindex exec_prefix -A prefix used in constructing the default values of some of the -variables listed below. The default value of @code{exec_prefix} should -be @code{$(prefix)}. -(If you are using Autoconf, write it as @samp{@@exec_prefix@@}.) - -Generally, @code{$(exec_prefix)} is used for directories that contain -machine-specific files (such as executables and subroutine libraries), -while @code{$(prefix)} is used directly for other directories. - -Running @samp{make install} with a different value of @code{exec_prefix} -from the one used to build the program should @emph{not} recompile the -program. -@end table - -Executable programs are installed in one of the following directories. - -@table @code -@item bindir -@vindex bindir -The directory for installing executable programs that users can run. -This should normally be @file{/usr/local/bin}, but write it as -@file{$(exec_prefix)/bin}. -(If you are using Autoconf, write it as @samp{@@bindir@@}.) - -@item sbindir -@vindex 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 @file{/usr/local/sbin}, but write it as -@file{$(exec_prefix)/sbin}. -(If you are using Autoconf, write it as @samp{@@sbindir@@}.) - -@item libexecdir -@vindex libexecdir -@comment This paragraph adjusted to avoid overfull hbox --roland 5jul94 -The directory for installing executable programs to be run by other -programs rather than by users. This directory should normally be -@file{/usr/local/libexec}, but write it as @file{$(exec_prefix)/libexec}. -(If you are using Autoconf, write it as @samp{@@libexecdir@@}.) - -The definition of @samp{libexecdir} is the same for all packages, so -you should install your data in a subdirectory thereof. Most packages -install their data under @file{$(libexecdir)/@var{package-name}/}, -possibly within additional subdirectories thereof, such as -@file{$(libexecdir)/@var{package-name}/@var{machine}/@var{version}}. -@end table - -Data files used by the program during its execution are divided into -categories in two ways. - -@itemize @bullet -@item -Some files are normally modified by programs; others are never normally -modified (though users may edit some of these). - -@item -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. -@end itemize - -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: - -@table @samp -@item datarootdir -The root of the directory tree for read-only architecture-independent -data files. This should normally be @file{/usr/local/share}, but -write it as @file{$(prefix)/share}. (If you are using Autoconf, write -it as @samp{@@datarootdir@@}.) @samp{datadir}'s default value is -based on this variable; so are @samp{infodir}, @samp{mandir}, and -others. - -@item datadir -The directory for installing idiosyncratic read-only -architecture-independent data files for this program. This is usually -the same place as @samp{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 @file{/usr/local/share}, but write it as -@file{$(datarootdir)}. (If you are using Autoconf, write it as -@samp{@@datadir@@}.) - -The definition of @samp{datadir} is the same for all packages, so you -should install your data in a subdirectory thereof. Most packages -install their data under @file{$(datadir)/@var{package-name}/}. - -@item 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, @file{/etc/passwd}, and so forth belong -here. All the files in this directory should be ordinary ASCII text -files. This directory should normally be @file{/usr/local/etc}, but -write it as @file{$(prefix)/etc}. -(If you are using Autoconf, write it as @samp{@@sysconfdir@@}.) - -Do not install executables here in this directory (they probably belong -in @file{$(libexecdir)} or @file{$(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 @file{$(localstatedir)}. - -@item sharedstatedir -The directory for installing architecture-independent data files which -the programs modify while they run. This should normally be -@file{/usr/local/com}, but write it as @file{$(prefix)/com}. -(If you are using Autoconf, write it as @samp{@@sharedstatedir@@}.) - -@item 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 @file{$(datadir)} or @file{$(sysconfdir)}. @file{$(localstatedir)} -should normally be @file{/usr/local/var}, but write it as -@file{$(prefix)/var}. -(If you are using Autoconf, write it as @samp{@@localstatedir@@}.) -@end table - -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 @samp{infodir}, but not all -need @samp{libdir} or @samp{lispdir}. - -@table @samp -@item includedir -@c rewritten to avoid overfull hbox --roland -The directory for installing header files to be included by user -programs with the C @samp{#include} preprocessor directive. This -should normally be @file{/usr/local/include}, but write it as -@file{$(prefix)/include}. -(If you are using Autoconf, write it as @samp{@@includedir@@}.) - -Most compilers other than GCC do not look for header files in directory -@file{/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 @code{includedir} and one -specified by @code{oldincludedir}. - -@item oldincludedir -The directory for installing @samp{#include} header files for use with -compilers other than GCC. This should normally be @file{/usr/include}. -(If you are using Autoconf, you can write it as @samp{@@oldincludedir@@}.) - -The Makefile commands should check whether the value of -@code{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 @file{foo.h}, then it should install the header -file in the @code{oldincludedir} directory if either (1) there is no -@file{foo.h} there or (2) the @file{foo.h} that exists came from the Foo -package. - -To tell whether @file{foo.h} came from the Foo package, put a magic -string in the file---part of a comment---and @code{grep} for that string. - -@item docdir -The directory for installing documentation files (other than Info) for -this package. By default, it should be -@file{/usr/local/share/doc/@var{yourpkg}}, but it should be written as -@file{$(datarootdir)/doc/@var{yourpkg}}. (If you are using Autoconf, -write it as @samp{@@docdir@@}.) The @var{yourpkg} subdirectory, which -may include a version number, prevents collisions among files with -common names, such as @file{README}. - -@item infodir -The directory for installing the Info files for this package. By -default, it should be @file{/usr/local/share/info}, but it should be -written as @file{$(datarootdir)/info}. (If you are using Autoconf, -write it as @samp{@@infodir@@}.) @code{infodir} is separate from -@code{docdir} for compatibility with existing practice. - -@item htmldir -@itemx dvidir -@itemx pdfdir -@itemx psdir -Directories for installing documentation files in the particular -format. They should all be set to @code{$(docdir)} by default. (If -you are using Autoconf, write them as @samp{@@htmldir@@}, -@samp{@@dvidir@@}, etc.) Packages which supply several translations -of their documentation should install them in -@samp{$(htmldir)/}@var{ll}, @samp{$(pdfdir)/}@var{ll}, etc. where -@var{ll} is a locale abbreviation such as @samp{en} or @samp{pt_BR}. - -@item libdir -The directory for object files and libraries of object code. Do not -install executables here, they probably ought to go in @file{$(libexecdir)} -instead. The value of @code{libdir} should normally be -@file{/usr/local/lib}, but write it as @file{$(exec_prefix)/lib}. -(If you are using Autoconf, write it as @samp{@@libdir@@}.) - -@item lispdir -The directory for installing any Emacs Lisp files in this package. By -default, it should be @file{/usr/local/share/emacs/site-lisp}, but it -should be written as @file{$(datarootdir)/emacs/site-lisp}. - -If you are using Autoconf, write the default as @samp{@@lispdir@@}. -In order to make @samp{@@lispdir@@} work, you need the following lines -in your @file{configure.in} file: - -@example -lispdir='$@{datarootdir@}/emacs/site-lisp' -AC_SUBST(lispdir) -@end example - -@item localedir -The directory for installing locale-specific message catalogs for this -package. By default, it should be @file{/usr/local/share/locale}, but -it should be written as @file{$(datarootdir)/locale}. (If you are -using Autoconf, write it as @samp{@@localedir@@}.) This directory -usually has a subdirectory per locale. -@end table - -Unix-style man pages are installed in one of the following: - -@table @samp -@item mandir -The top-level directory for installing the man pages (if any) for this -package. It will normally be @file{/usr/local/share/man}, but you -should write it as @file{$(datarootdir)/man}. (If you are using -Autoconf, write it as @samp{@@mandir@@}.) - -@item man1dir -The directory for installing section 1 man pages. Write it as -@file{$(mandir)/man1}. -@item man2dir -The directory for installing section 2 man pages. Write it as -@file{$(mandir)/man2} -@item @dots{} - -@strong{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.} - -@item manext -The file name extension for the installed man page. This should contain -a period followed by the appropriate digit; it should normally be @samp{.1}. - -@item man1ext -The file name extension for installed section 1 man pages. -@item man2ext -The file name extension for installed section 2 man pages. -@item @dots{} -Use these names instead of @samp{manext} if the package needs to install man -pages in more than one section of the manual. -@end table - -And finally, you should set the following variable: - -@table @samp -@item srcdir -The directory for the sources being compiled. The value of this -variable is normally inserted by the @code{configure} shell script. -(If you are using Autoconf, use @samp{srcdir = @@srcdir@@}.) -@end table - -For example: - -@smallexample -@c I have changed some of the comments here slightly to fix an overfull -@c hbox, so the make manual can format correctly. --roland -# 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 -@end smallexample - -If your program installs a large number of files into one of the -standard user-specified directories, it might be useful to group them -into a subdirectory particular to that program. If you do this, you -should write the @code{install} rule to create these subdirectories. - -Do not expect the user to include the subdirectory name in the value of -any of the variables listed above. The idea of having a uniform set of -variable names for installation directories is to enable the user to -specify the exact same values for several different GNU packages. In -order for this to be useful, all the packages must be designed so that -they will work sensibly when the user does so. - -At times, not all of these variables may be implemented in the current -release of Autoconf and/or Automake; but as of Autoconf@tie{}2.60, we -believe all of them are. When any are missing, the descriptions here -serve as specifications for what Autoconf will implement. As a -programmer, you can either use a development version of Autoconf or -avoid using these variables until a stable release is made which -supports them. - - -@node Standard Targets -@section Standard Targets for Users - -All GNU programs should have the following targets in their Makefiles: - -@table @samp -@item 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 @samp{-g}, so -that executable programs have debugging symbols. Users who don't mind -being helpless can strip the executables later if they wish. - -@item 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. Devil-may-care users can -use the @code{install-strip} target to do that. - -If possible, write the @code{install} target rule so that it does not -modify anything in the directory where the program was built, provided -@samp{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 @code{prefix} and -@code{exec_prefix}, as well as all subdirectories that are needed. -One way to do this is by means of an @code{installdirs} target -as described below. - -Use @samp{-} before any command for installing a man page, so that -@code{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 @file{$(infodir)} -with @code{$(INSTALL_DATA)} (@pxref{Command Variables}), and then run -the @code{install-info} program if it is present. @code{install-info} -is a program that edits the Info @file{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: - -@comment This example has been carefully formatted for the Make manual. -@comment Please do not reformat it without talking to bug-make@gnu.org. -@smallexample -$(DESTDIR)$(infodir)/foo.info: foo.info - $(POST_INSTALL) -# There may be a newer info file in . than in srcdir. - -if test -f foo.info; then d=.; \ - else d=$(srcdir); fi; \ - $(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@@; \ -# Run install-info only if it exists. -# Use `if' instead of just prepending `-' to the -# line so we notice real errors from install-info. -# We use `$(SHELL) -c' because some shells do not -# fail gracefully when there is an unknown command. - 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 -@end smallexample - -When writing the @code{install} target, you must classify all the -commands into three categories: normal ones, @dfn{pre-installation} -commands and @dfn{post-installation} commands. @xref{Install Command -Categories}. - -@item install-html -@itemx install-dvi -@itemx install-pdf -@itemx 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 @code{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 @code{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 @code{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 @code{install-@var{format}} targets invoke the -commands for the @var{format} target, for example, by making -@var{format} a dependency. - -@item uninstall -Delete all the installed files---the copies that the @samp{install} -and @samp{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. @xref{Install Command Categories}. - -@item install-strip -Like @code{install}, but strip the executable files while installing -them. In simple cases, this target can use the @code{install} target in -a simple way: - -@smallexample -install-strip: - $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \ - install -@end smallexample - -But if the package installs scripts as well as real executables, the -@code{install-strip} target can't just refer to the @code{install} -target; it has to strip the executables but not the scripts. - -@code{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. - -@comment The gratuitous blank line here is to make the table look better -@comment in the printed Make manual. Please leave it in. -@item 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 @samp{mkdir -p}, since they could have existed anyway. - -Delete @file{.dvi} files here if they are not part of the distribution. - -@item 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, @samp{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 @samp{mkdir -p}, since they -could have existed anyway. - -@item mostlyclean -Like @samp{clean}, but may refrain from deleting a few files that people -normally don't want to recompile. For example, the @samp{mostlyclean} -target for GCC does not delete @file{libgcc.a}, because recompiling it -is rarely necessary and takes a lot of time. - -@item maintainer-clean -Delete almost everything that can be reconstructed with this Makefile. -This typically includes everything deleted by @code{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 -@samp{make maintainer-clean} should not delete @file{configure} even -if @file{configure} can be remade using a rule in the Makefile. More -generally, @samp{make maintainer-clean} should not delete anything -that needs to exist in order to run @file{configure} and then begin to -build the program. Also, there is no need to delete parent -directories that were created with @samp{mkdir -p}, since they could -have existed anyway. These are the only exceptions; -@code{maintainer-clean} should delete everything else that can be -rebuilt. - -The @samp{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 @samp{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 -@code{maintainer-clean} target should start with these two: - -@smallexample -@@echo 'This command is intended for maintainers to use; it' -@@echo 'deletes files that may need special tools to rebuild.' -@end smallexample - -@item TAGS -Update a tags table for this program. -@c ADR: how? - -@item info -Generate any Info files needed. The best way to write the rules is as -follows: - -@smallexample -info: foo.info - -foo.info: foo.texi chap1.texi chap2.texi - $(MAKEINFO) $(srcdir)/foo.texi -@end smallexample - -@noindent -You must define the variable @code{MAKEINFO} in the Makefile. It should -run the @code{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. - -@item dvi -@itemx html -@itemx pdf -@itemx 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 @code{all} target; the user must manually invoke them. - -Here's an example rule for generating DVI files from Texinfo: - -@smallexample -dvi: foo.dvi - -foo.dvi: foo.texi chap1.texi chap2.texi - $(TEXI2DVI) $(srcdir)/foo.texi -@end smallexample - -@noindent -You must define the variable @code{TEXI2DVI} in the Makefile. It should -run the program @code{texi2dvi}, which is part of the Texinfo -distribution.@footnote{@code{texi2dvi} uses @TeX{} to do the real work -of formatting. @TeX{} is not distributed with Texinfo.} Alternatively, -write just the dependencies, and allow GNU @code{make} to provide the command. - -Here's another example, this one for generating HTML from Texinfo: - -@smallexample -html: foo.html - -foo.html: foo.texi chap1.texi chap2.texi - $(TEXI2HTML) $(srcdir)/foo.texi -@end smallexample - -@noindent -Again, you would define the variable @code{TEXI2HTML} in the Makefile; -for example, it might run @code{makeinfo --no-split --html} -(@command{makeinfo} is part of the Texinfo distribution). - -@item 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 @file{gcc-1.40}. - -The easiest way to do this is to create a subdirectory appropriately -named, use @code{ln} or @code{cp} to install the proper files in it, and -then @code{tar} that subdirectory. - -Compress the tar file with @code{gzip}. For example, the actual -distribution file for GCC version 1.40 is called @file{gcc-1.40.tar.gz}. - -The @code{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. -@ifset CODESTD -@xref{Releases, , Making Releases}. -@end ifset -@ifclear CODESTD -@xref{Releases, , Making Releases, standards, GNU Coding Standards}. -@end ifclear - -@item 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. -@end table - -The following targets are suggested as conventional names, for programs -in which they are useful. - -@table @code -@item installcheck -Perform installation tests (if any). The user must build and install -the program before running the tests. You should not assume that -@file{$(bindir)} is in the search path. - -@item installdirs -It's useful to add a target named @samp{installdirs} to create the -directories where files are installed, and their parent directories. -There is a script called @file{mkinstalldirs} which is convenient for -this; you can find it in the Texinfo package. -@c It's in /gd/gnu/lib/mkinstalldirs. -You can use a rule like this: - -@comment This has been carefully formatted to look decent in the Make manual. -@comment Please be sure not to make it extend any further to the right.--roland -@smallexample -# Make sure all installation directories (e.g. $(bindir)) -# actually exist by making them if necessary. -installdirs: mkinstalldirs - $(srcdir)/mkinstalldirs $(bindir) $(datadir) \ - $(libdir) $(infodir) \ - $(mandir) -@end smallexample - -@noindent -or, if you wish to support @env{DESTDIR}, - -@smallexample -# 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) -@end smallexample - -This rule should not modify the directories where compilation is done. -It should do nothing but create installation directories. -@end table - -@node Install Command Categories -@section Install Command Categories - -@cindex pre-installation commands -@cindex post-installation commands -When writing the @code{install} target, you must classify all the -commands into three categories: normal ones, @dfn{pre-installation} -commands and @dfn{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 -@code{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 @code{install} rule into these three -categories, insert @dfn{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 -@emph{should not} define them in the makefile). - -Here are the three possible category lines, each with a comment that -explains what it means: - -@smallexample - $(PRE_INSTALL) # @r{Pre-install commands follow.} - $(POST_INSTALL) # @r{Post-install commands follow.} - $(NORMAL_INSTALL) # @r{Normal commands follow.} -@end smallexample - -If you don't use a category line at the beginning of the @code{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 @code{uninstall}: - -@smallexample - $(PRE_UNINSTALL) # @r{Pre-uninstall commands follow.} - $(POST_UNINSTALL) # @r{Post-uninstall commands follow.} - $(NORMAL_UNINSTALL) # @r{Normal commands follow.} -@end smallexample - -Typically, a pre-uninstall command would be used for deleting entries -from the Info directory. - -If the @code{install} or @code{uninstall} target has any dependencies -which act as subroutines of installation, then you should start -@emph{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: - -@example -[ 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 -@end example - -@cindex binary packages -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 @option{-s} option to -@command{make} is needed to silence messages about entering -subdirectories): - -@smallexample -make -s -n install -o all \ - PRE_INSTALL=pre-install \ - POST_INSTALL=post-install \ - NORMAL_INSTALL=normal-install \ - | gawk -f pre-install.awk -@end smallexample - -@noindent -where the file @file{pre-install.awk} could contain this: - -@smallexample -$0 ~ /^(normal-install|post-install)[ \t]*$/ @{on = 0@} -on @{print $0@} -$0 ~ /^pre-install[ \t]*$/ @{on = 1@} -@end smallexample |