diff options
| author | Paul Brook <paul@codesourcery.com> | 2005-04-29 19:57:05 +0400 |
|---|---|---|
| committer | Paul Brook <paul@codesourcery.com> | 2005-04-29 19:57:05 +0400 |
| commit | a67c36780bb76c2f79920742029b35e5b75c88d3 (patch) | |
| tree | 5722026048fbf72516e56687c809439b447374ce | |
| parent | c6615227ee722074c548e915e5cfb411ffe906b0 (diff) | |
Remove generated documentation and translation files from CVS.
| -rw-r--r-- | etc/configure.info | 2771 | ||||
| -rw-r--r-- | etc/standards.info | 4930 |
2 files changed, 0 insertions, 7701 deletions
diff --git a/etc/configure.info b/etc/configure.info deleted file mode 100644 index 589b25c41..000000000 --- a/etc/configure.info +++ /dev/null @@ -1,2771 +0,0 @@ -This is configure.info, produced by makeinfo version 4.7 from -.././etc/configure.texi. - -INFO-DIR-SECTION GNU admin -START-INFO-DIR-ENTRY -* configure: (configure). The GNU configure and build system -END-INFO-DIR-ENTRY - - This file documents the GNU configure and build system. - - Copyright (C) 1998 Cygnus Solutions. - - Permission is granted to make and distribute verbatim copies of this -manual provided the copyright notice and this permission notice are -preserved on all copies. - - Permission is granted to copy and distribute modified versions of -this manual under the conditions for verbatim copying, provided that -the entire resulting derived work is distributed under the terms of a -permission notice identical to this one. - - Permission is granted to copy and distribute translations of this -manual into another language, under the above conditions for modified -versions, except that this permission notice may be stated in a -translation approved by the Foundation. - - -File: configure.info, Node: Top, Next: Introduction, Up: (dir) - -GNU configure and build system -****************************** - -The GNU configure and build system. - -* Menu: - -* Introduction:: Introduction. -* Getting Started:: Getting Started. -* Files:: Files. -* Configuration Names:: Configuration Names. -* Cross Compilation Tools:: Cross Compilation Tools. -* Canadian Cross:: Canadian Cross. -* Cygnus Configure:: Cygnus Configure. -* Multilibs:: Multilibs. -* FAQ:: Frequently Asked Questions. -* Index:: Index. - - -File: configure.info, Node: Introduction, Next: Getting Started, Prev: Top, Up: Top - -1 Introduction -************** - -This document describes the GNU configure and build systems. It -describes how autoconf, automake, libtool, and make fit together. It -also includes a discussion of the older Cygnus configure system. - - This document does not describe in detail how to use each of the -tools; see the respective manuals for that. Instead, it describes -which files the developer must write, which files are machine generated -and how they are generated, and where certain common problems should be -addressed. - - This document draws on several sources, including the autoconf -manual by David MacKenzie (*note autoconf overview: (autoconf)Top.), -the automake manual by David MacKenzie and Tom Tromey (*note automake -overview: (automake)Top.), the libtool manual by Gordon Matzigkeit -(*note libtool overview: (libtool)Top.), and the Cygnus configure -manual by K. Richard Pixley. - -* Menu: - -* Goals:: Goals. -* Tools:: The tools. -* History:: History. -* Building:: Building. - - -File: configure.info, Node: Goals, Next: Tools, Up: Introduction - -1.1 Goals -========= - -The GNU configure and build system has two main goals. - - The first is to simplify the development of portable programs. The -system permits the developer to concentrate on writing the program, -simplifying many details of portability across Unix and even Windows -systems, and permitting the developer to describe how to build the -program using simple rules rather than complex Makefiles. - - The second is to simplify the building of programs distributed as -source code. All programs are built using a simple, standardized, two -step process. The program builder need not install any special tools in -order to build the program. - - -File: configure.info, Node: Tools, Next: History, Prev: Goals, Up: Introduction - -1.2 Tools -========= - -The GNU configure and build system is comprised of several different -tools. Program developers must build and install all of these tools. - - People who just want to build programs from distributed sources -normally do not need any special tools beyond a Unix shell, a make -program, and a C compiler. - -autoconf - provides a general portability framework, based on testing the - features of the host system at build time. - -automake - a system for describing how to build a program, permitting the - developer to write a simplified `Makefile'. - -libtool - a standardized approach to building shared libraries. - -gettext - provides a framework for translation of text messages into other - languages; not really discussed in this document. - -m4 - autoconf requires the GNU version of m4; the standard Unix m4 does - not suffice. - -perl - automake requires perl. - - -File: configure.info, Node: History, Next: Building, Prev: Tools, Up: Introduction - -1.3 History -=========== - -This is a very brief and probably inaccurate history. - - As the number of Unix variants increased during the 1980s, it became -harder to write programs which could run on all variants. While it was -often possible to use `#ifdef' to identify particular systems, -developers frequently did not have access to every system, and the -characteristics of some systems changed from version to version. - - By 1992, at least three different approaches had been developed: - * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael - Manfredi. - - * The Cygnus configure script, by K. Richard Pixley, and the gcc - configure script, by Richard Stallman. These use essentially the - same approach, and the developers communicated regularly. - - * The autoconf program, by David MacKenzie. - - The Metaconfig program is still used for Perl and a few other -programs. It is part of the Dist package. I do not know if it is -being developed. - - In 1994, David MacKenzie and others modified autoconf to incorporate -all the features of Cygnus configure. Since then, there has been a -slow but steady conversion of GNU programs from Cygnus configure to -autoconf. gcc has been converted, eliminating the gcc configure script. - - GNU autoconf was regularly maintained until late 1996. As of this -writing in June, 1998, it has no public maintainer. - - Most programs are built using the make program, which requires the -developer to write Makefiles describing how to build the programs. -Since most programs are built in pretty much the same way, this led to a -lot of duplication. - - The X Window system is built using the imake tool, which uses a -database of rules to eliminate the duplication. However, building a -tool which was developed using imake requires that the builder have -imake installed, violating one of the goals of the GNU system. - - The new BSD make provides a standard library of Makefile fragments, -which permits developers to write very simple Makefiles. However, this -requires that the builder install the new BSD make program. - - In 1994, David MacKenzie wrote the first version of automake, which -permitted writing a simple build description which was converted into a -Makefile which could be used by the standard make program. In 1995, Tom -Tromey completely rewrote automake in Perl, and he continues to enhance -it. - - Various free packages built libraries, and by around 1995 several -included support to build shared libraries on various platforms. -However, there was no consistent approach. In early 1996, Gordon -Matzigkeit began working on libtool, which provided a standardized -approach to building shared libraries. This was integrated into -automake from the start. - - The development of automake and libtool was driven by the GNITS -project, a group of GNU maintainers who designed standardized tools to -help meet the GNU coding standards. - - -File: configure.info, Node: Building, Prev: History, Up: Introduction - -1.4 Building -============ - -Most readers of this document should already know how to build a tool by -running `configure' and `make'. This section may serve as a quick -introduction or reminder. - - Building a tool is normally as simple as running `configure' -followed by `make'. You should normally run `configure' from an empty -directory, using some path to refer to the `configure' script in the -source directory. The directory in which you run `configure' is called -the "object directory". - - In order to use a object directory which is different from the source -directory, you must be using the GNU version of `make', which has the -required `VPATH' support. Despite this restriction, using a different -object directory is highly recommended: - * It keeps the files generated during the build from cluttering up - your sources. - - * It permits you to remove the built files by simply removing the - entire build directory. - - * It permits you to build from the same sources with several sets of - configure options simultaneously. - - If you don't have GNU `make', you will have to run `configure' in -the source directory. All GNU packages should support this; in -particular, GNU packages should not assume the presence of GNU `make'. - - After running `configure', you can build the tools by running `make'. - - To install the tools, run `make install'. Installing the tools will -copy the programs and any required support files to the "installation -directory". The location of the installation directory is controlled -by `configure' options, as described below. - - In the Cygnus tree at present, the info files are built and -installed as a separate step. To build them, run `make info'. To -install them, run `make install-info'. - - All `configure' scripts support a wide variety of options. The most -interesting ones are `--with' and `--enable' options which are -generally specific to particular tools. You can usually use the -`--help' option to get a list of interesting options for a particular -configure script. - - The only generic options you are likely to use are the `--prefix' -and `--exec-prefix' options. These options are used to specify the -installation directory. - - The directory named by the `--prefix' option will hold machine -independent files such as info files. - - The directory named by the `--exec-prefix' option, which is normally -a subdirectory of the `--prefix' directory, will hold machine dependent -files such as executables. - - The default for `--prefix' is `/usr/local'. The default for -`--exec-prefix' is the value used for `--prefix'. - - The convention used in Cygnus releases is to use a `--prefix' option -of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and -to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where -HOST is the configuration name of the host system (*note Configuration -Names::). - - Do not use either the source or the object directory as the -installation directory. That will just lead to confusion. - - -File: configure.info, Node: Getting Started, Next: Files, Prev: Introduction, Up: Top - -2 Getting Started -***************** - -To start using the GNU configure and build system with your software -package, you must write three files, and you must run some tools to -manually generate additional files. - -* Menu: - -* Write configure.in:: Write configure.in. -* Write Makefile.am:: Write Makefile.am. -* Write acconfig.h:: Write acconfig.h. -* Generate files:: Generate files. -* Getting Started Example:: Example. - - -File: configure.info, Node: Write configure.in, Next: Write Makefile.am, Up: Getting Started - -2.1 Write configure.in -====================== - -You must first write the file `configure.in'. This is an autoconf -input file, and the autoconf manual describes in detail what this file -should look like. - - You will write tests in your `configure.in' file to check for -conditions that may change from one system to another, such as the -presence of particular header files or functions. - - For example, not all systems support the `gettimeofday' function. -If you want to use the `gettimeofday' function when it is available, -and to use some other function when it is not, you would check for this -by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'. - - When the configure script is run at build time, this will arrange to -define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the -`gettimeofday' function is available, and to not define the macro at -all if the function is not available. Your code can then use `#ifdef' -to test whether it is safe to call `gettimeofday'. - - If you have an existing body of code, the `autoscan' program may -help identify potential portability problems, and hence configure tests -that you will want to use. *Note Invoking autoscan: (autoconf)Invoking -autoscan. - - Another handy tool for an existing body of code is `ifnames'. This -will show you all the preprocessor conditionals that the code already -uses. *Note Invoking ifnames: (autoconf)Invoking ifnames. - - Besides the portability tests which are specific to your particular -package, every `configure.in' file should contain the following macros. - -`AC_INIT' - This macro takes a single argument, which is the name of a file in - your package. For example, `AC_INIT(foo.c)'. - -`AC_PREREQ(VERSION)' - This macro is optional. It may be used to indicate the version of - `autoconf' that you are using. This will prevent users from - running an earlier version of `autoconf' and perhaps getting an - invalid `configure' script. For example, `AC_PREREQ(2.12)'. - -`AM_INIT_AUTOMAKE' - This macro takes two arguments: the name of the package, and a - version number. For example, `AM_INIT_AUTOMAKE(foo, 1.0)'. (This - macro is not needed if you are not using automake). - -`AM_CONFIG_HEADER' - This macro names the header file which will hold the preprocessor - macro definitions at run time. Normally this should be - `config.h'. Your sources would then use `#include "config.h"' to - include it. - - This macro may optionally name the input file for that header - file; by default, this is `config.h.in', but that file name works - poorly on DOS filesystems. Therefore, it is often better to name - it explicitly as `config.in'. - - This is what you should normally put in `configure.in': - AM_CONFIG_HEADER(config.h:config.in) - - (If you are not using automake, use `AC_CONFIG_HEADER' rather than - `AM_CONFIG_HEADER'). - -`AM_MAINTAINER_MODE' - This macro always appears in Cygnus configure scripts. Other - programs may or may not use it. - - If this macro is used, the `--enable-maintainer-mode' option is - required to enable automatic rebuilding of generated files used by - the configure system. This of course requires that developers be - aware of, and use, that option. - - If this macro is not used, then the generated files will always be - rebuilt automatically. This will cause problems if the wrong - versions of autoconf, automake, or others are in the builder's - `PATH'. - - (If you are not using automake, you do not need to use this macro). - -`AC_EXEEXT' - Either this macro or `AM_EXEEXT' always appears in Cygnus configure - files. Other programs may or may not use one of them. - - This macro looks for the executable suffix used on the host - system. On Unix systems, this is the empty string. On Windows - systems, this is `.exe'. This macro directs automake to use the - executable suffix as appropriate when creating programs. This - macro does not take any arguments. - - The `AC_EXEEXT' form is new, and is part of a Cygnus patch to - autoconf to support compiling with Visual C++. Older programs use - `AM_EXEEXT' instead. - - (Programs which do not use automake use neither `AC_EXEEXT' nor - `AM_EXEEXT'). - -`AC_PROG_CC' - If you are writing C code, you will normally want to use this - macro. It locates the C compiler to use. It does not take any - arguments. - - However, if this `configure.in' file is for a library which is to - be compiled by a cross compiler which may not fully work, then you - will not want to use `AC_PROG_CC'. Instead, you will want to use a - variant which does not call the macro `AC_PROG_CC_WORKS'. Examples - can be found in various `configure.in' files for libraries that are - compiled with cross compilers, such as libiberty or libgloss. - This is essentially a bug in autoconf, and there will probably be - a better workaround at some point. - -`AC_PROG_CXX' - If you are writing C++ code, you will want to use this macro. It - locates the C++ compiler to use. It does not take any arguments. - The same cross compiler comments apply as for `AC_PROG_CC'. - -`AM_PROG_LIBTOOL' - If you want to build libraries, and you want to permit them to be - shared, or you want to link against libraries which were built - using libtool, then you will need this macro. This macro is - required in order to use libtool. - - By default, this will cause all libraries to be built as shared - libraries. To prevent this-to change the default-use - `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'. The configure - options `--enable-shared' and `--disable-shared' may be used to - override the default at build time. - -`AC_DEFINE(_GNU_SOURCE)' - GNU packages should normally include this line before any other - feature tests. This defines the macro `_GNU_SOURCE' when - compiling, which directs the libc header files to provide the - standard GNU system interfaces including all GNU extensions. If - this macro is not defined, certain GNU extensions may not be - available. - -`AC_OUTPUT' - This macro takes a list of file names which the configure process - should produce. This is normally a list of one or more `Makefile' - files in different directories. If your package lives entirely in - a single directory, you would use simply `AC_OUTPUT(Makefile)'. - If you also have, for example, a `lib' subdirectory, you would use - `AC_OUTPUT(Makefile lib/Makefile)'. - - If you want to use locally defined macros in your `configure.in' -file, then you will need to write a `acinclude.m4' file which defines -them (if not using automake, this file is called `aclocal.m4'). -Alternatively, you can put separate macros in an `m4' subdirectory, and -put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the -`aclocal' program will be able to find them. - - The different macro prefixes indicate which tool defines the macro. -Macros which start with `AC_' are part of autoconf. Macros which start -with `AM_' are provided by automake or libtool. - - -File: configure.info, Node: Write Makefile.am, Next: Write acconfig.h, Prev: Write configure.in, Up: Getting Started - -2.2 Write Makefile.am -===================== - -You must write the file `Makefile.am'. This is an automake input file, -and the automake manual describes in detail what this file should look -like. - - The automake commands in `Makefile.am' mostly look like variable -assignments in a `Makefile'. automake recognizes special variable -names, and automatically add make rules to the output as needed. - - There will be one `Makefile.am' file for each directory in your -package. For each directory with subdirectories, the `Makefile.am' -file should contain the line - SUBDIRS = DIR DIR ... - where each DIR is the name of a subdirectory. - - For each `Makefile.am', there should be a corresponding `Makefile' -in the `AC_OUTPUT' macro in `configure.in'. - - Every `Makefile.am' written at Cygnus should contain the line - AUTOMAKE_OPTIONS = cygnus - This puts automake into Cygnus mode. See the automake manual for -details. - - You may to include the version number of `automake' that you are -using on the `AUTOMAKE_OPTIONS' line. For example, - AUTOMAKE_OPTIONS = cygnus 1.3 - This will prevent users from running an earlier version of -`automake' and perhaps getting an invalid `Makefile.in'. - - If your package builds a program, then in the directory where that -program is built you will normally want a line like - bin_PROGRAMS = PROGRAM - where PROGRAM is the name of the program. You will then want a line -like - PROGRAM_SOURCES = FILE FILE ... - where each FILE is the name of a source file to link into the -program (e.g., `foo.c'). - - If your package builds a library, and you do not want the library to -ever be built as a shared library, then in the directory where that -library is built you will normally want a line like - lib_LIBRARIES = libNAME.a - where `libNAME.a' is the name of the library. You will then want a -line like - libNAME_a_SOURCES = FILE FILE ... - where each FILE is the name of a source file to add to the library. - - If your package builds a library, and you want to permit building the -library as a shared library, then in the directory where that library is -built you will normally want a line like - lib_LTLIBRARIES = libNAME.la - The use of `LTLIBRARIES', and the `.la' extension, indicate a -library to be built using libtool. As usual, you will then want a line -like - libNAME_la_SOURCES = FILE FILE ... - - The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and -`lib_LIBRARIES' are not arbitrary. They refer to particular -directories, which may be set by the `--bindir' and `--libdir' options -to `configure'. If those options are not used, the default values are -based on the `--prefix' or `--exec-prefix' options to `configure'. It -is possible to use other names if the program or library should be -installed in some other directory. - - The `Makefile.am' file may also contain almost anything that may -appear in a normal `Makefile'. automake also supports many other -special variables, as well as conditionals. - - See the automake manual for more information. - - -File: configure.info, Node: Write acconfig.h, Next: Generate files, Prev: Write Makefile.am, Up: Getting Started - -2.3 Write acconfig.h -==================== - -If you are generating a portability header file, (i.e., you are using -`AM_CONFIG_HEADER' in `configure.in'), then you will have to write a -`acconfig.h' file. It will have to contain the following lines. - - /* Name of package. */ - #undef PACKAGE - - /* Version of package. */ - #undef VERSION - - This requirement is really a bug in the system, and the requirement -may be eliminated at some later date. - - The `acconfig.h' file will also similar comment and `#undef' lines -for any unusual macros in the `configure.in' file, including any macro -which appears in a `AC_DEFINE' macro. - - In particular, if you are writing a GNU package and therefore include -`AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will -need lines like this in `acconfig.h': - /* Enable GNU extensions. */ - #undef _GNU_SOURCE - - Normally the `autoheader' program will inform you of any such -requirements by printing an error message when it is run. However, if -you do anything particular odd in your `configure.in' file, you will -have to make sure that the right entries appear in `acconfig.h', since -otherwise the results of the tests may not be available in the -`config.h' file which your code will use. - - (Thee `PACKAGE' and `VERSION' lines are not required if you are not -using automake, and in that case you may not need a `acconfig.h' file -at all). - - -File: configure.info, Node: Generate files, Next: Getting Started Example, Prev: Write acconfig.h, Up: Getting Started - -2.4 Generate files -================== - -Once you have written `configure.in', `Makefile.am', `acconfig.h', and -possibly `acinclude.m4', you must use autoconf and automake programs to -produce the first versions of the generated files. This is done by -executing the following sequence of commands. - - aclocal - autoconf - autoheader - automake - - The `aclocal' and `automake' commands are part of the automake -package, and the `autoconf' and `autoheader' commands are part of the -autoconf package. - - If you are using a `m4' subdirectory for your macros, you will need -to use the `-I m4' option when you run `aclocal'. - - If you are not using the Cygnus tree, use the `-a' option when -running `automake' command in order to copy the required support files -into your source directory. - - If you are using libtool, you must build and install the libtool -package with the same `--prefix' and `--exec-prefix' options as you -used with the autoconf and automake packages. You must do this before -running any of the above commands. If you are not using the Cygnus -tree, you will need to run the `libtoolize' program to copy the libtool -support files into your directory. - - Once you have managed to run these commands without getting any -errors, you should create a new empty directory, and run the `configure' -script which will have been created by `autoconf' with the -`--enable-maintainer-mode' option. This will give you a set of -Makefiles which will include rules to automatically rebuild all the -generated files. - - After doing that, whenever you have changed some of the input files -and want to regenerated the other files, go to your object directory -and run `make'. Doing this is more reliable than trying to rebuild the -files manually, because there are complex order dependencies and it is -easy to forget something. - - -File: configure.info, Node: Getting Started Example, Prev: Generate files, Up: Getting Started - -2.5 Example -=========== - -Let's consider a trivial example. - - Suppose we want to write a simple version of `touch'. Our program, -which we will call `poke', will take a single file name argument, and -use the `utime' system call to set the modification and access times of -the file to the current time. We want this program to be highly -portable. - - We'll first see what this looks like without using autoconf and -automake, and then see what it looks like with them. - -* Menu: - -* Getting Started Example 1:: First Try. -* Getting Started Example 2:: Second Try. -* Getting Started Example 3:: Third Try. -* Generate Files in Example:: Generate Files. - - -File: configure.info, Node: Getting Started Example 1, Next: Getting Started Example 2, Up: Getting Started Example - -2.5.1 First Try ---------------- - -Here is our first try at `poke.c'. Note that we've written it without -ANSI/ISO C prototypes, since we want it to be highly portable. - - #include <stdio.h> - #include <stdlib.h> - #include <sys/types.h> - #include <utime.h> - - int - main (argc, argv) - int argc; - char **argv; - { - if (argc != 2) - { - fprintf (stderr, "Usage: poke file\n"); - exit (1); - } - - if (utime (argv[1], NULL) < 0) - { - perror ("utime"); - exit (1); - } - - exit (0); - } - - We also write a simple `Makefile'. - - CC = gcc - CFLAGS = -g -O2 - - all: poke - - poke: poke.o - $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o - - So far, so good. - - Unfortunately, there are a few problems. - - On older Unix systems derived from BSD 4.3, the `utime' system call -does not accept a second argument of `NULL'. On those systems, we need -to pass a pointer to `struct utimbuf' structure. Unfortunately, even -older systems don't define that structure; on those systems, we need to -pass an array of two `long' values. - - The header file `stdlib.h' was invented by ANSI C, and older systems -don't have a copy. We included it above to get a declaration of `exit'. - - We can find some of these portability problems by running -`autoscan', which will create a `configure.scan' file which we can use -as a prototype for our `configure.in' file. I won't show the output, -but it will notice the potential problems with `utime' and `stdlib.h'. - - In our `Makefile', we don't provide any way to install the program. -This doesn't matter much for such a simple example, but a real program -will need an `install' target. For that matter, we will also want a -`clean' target. - - -File: configure.info, Node: Getting Started Example 2, Next: Getting Started Example 3, Prev: Getting Started Example 1, Up: Getting Started Example - -2.5.2 Second Try ----------------- - -Here is our second try at this program. - - We modify `poke.c' to use preprocessor macros to control what -features are available. (I've cheated a bit by using the same macro -names which autoconf will use). - - #include <stdio.h> - - #ifdef STDC_HEADERS - #include <stdlib.h> - #endif - - #include <sys/types.h> - - #ifdef HAVE_UTIME_H - #include <utime.h> - #endif - - #ifndef HAVE_UTIME_NULL - - #include <time.h> - - #ifndef HAVE_STRUCT_UTIMBUF - - struct utimbuf - { - long actime; - long modtime; - }; - - #endif - - static int - utime_now (file) - char *file; - { - struct utimbuf now; - - now.actime = now.modtime = time (NULL); - return utime (file, &now); - } - - #define utime(f, p) utime_now (f) - - #endif /* HAVE_UTIME_NULL */ - - int - main (argc, argv) - int argc; - char **argv; - { - if (argc != 2) - { - fprintf (stderr, "Usage: poke file\n"); - exit (1); - } - - if (utime (argv[1], NULL) < 0) - { - perror ("utime"); - exit (1); - } - - exit (0); - } - - Here is the associated `Makefile'. We've added support for the -preprocessor flags we use. We've also added `install' and `clean' -targets. - - # Set this to your installation directory. - bindir = /usr/local/bin - - # Uncomment this if you have the standard ANSI/ISO C header files. - # STDC_HDRS = -DSTDC_HEADERS - - # Uncomment this if you have utime.h. - # UTIME_H = -DHAVE_UTIME_H - - # Uncomment this if utime (FILE, NULL) works on your system. - # UTIME_NULL = -DHAVE_UTIME_NULL - - # Uncomment this if struct utimbuf is defined in utime.h. - # UTIMBUF = -DHAVE_STRUCT_UTIMBUF - - CC = gcc - CFLAGS = -g -O2 - - ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS) - - all: poke - - poke: poke.o - $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o - - .c.o: - $(CC) -c $(ALL_CFLAGS) poke.c - - install: poke - cp poke $(bindir)/poke - - clean: - rm poke poke.o - - Some problems with this approach should be clear. - - Users who want to compile poke will have to know how `utime' works -on their systems, so that they can uncomment the `Makefile' correctly. - - The installation is done using `cp', but many systems have an -`install' program which may be used, and which supports optional -features such as stripping debugging information out of the installed -binary. - - The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS' -follows the requirements of the GNU standards. This is convenient for -all packages, since it reduces surprises for users. However, it is -easy to get the details wrong, and wind up with a slightly nonstandard -distribution. - - -File: configure.info, Node: Getting Started Example 3, Next: Generate Files in Example, Prev: Getting Started Example 2, Up: Getting Started Example - -2.5.3 Third Try ---------------- - -For our third try at this program, we will write a `configure.in' -script to discover the configuration features on the host system, rather -than requiring the user to edit the `Makefile'. We will also write a -`Makefile.am' rather than a `Makefile'. - - The only change to `poke.c' is to add a line at the start of the -file: - #include "config.h" - - The new `configure.in' file is as follows. - - AC_INIT(poke.c) - AM_INIT_AUTOMAKE(poke, 1.0) - AM_CONFIG_HEADER(config.h:config.in) - AC_PROG_CC - AC_HEADER_STDC - AC_CHECK_HEADERS(utime.h) - AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF)) - AC_FUNC_UTIME_NULL - AC_OUTPUT(Makefile) - - The first four macros in this file, and the last one, were described -above; see *Note Write configure.in::. If we omit these macros, then -when we run `automake' we will get a reminder that we need them. - - The other macros are standard autoconf macros. - -`AC_HEADER_STDC' - Check for standard C headers. - -`AC_CHECK_HEADERS' - Check whether a particular header file exists. - -`AC_EGREP_HEADER' - Check for a particular string in a particular header file, in this - case checking for `utimbuf' in `utime.h'. - -`AC_FUNC_UTIME_NULL' - Check whether `utime' accepts a NULL second argument to set the - file change time to the current time. - - See the autoconf manual for a more complete description. - - The new `Makefile.am' file is as follows. Note how simple this is -compared to our earlier `Makefile'. - - bin_PROGRAMS = poke - - poke_SOURCES = poke.c - - This means that we should build a single program name `poke'. It -should be installed in the binary directory, which we called `bindir' -earlier. The program `poke' is built from the source file `poke.c'. - - We must also write a `acconfig.h' file. Besides `PACKAGE' and -`VERSION', which must be mentioned for all packages which use automake, -we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an -`AC_DEFINE'. - - /* Name of package. */ - #undef PACKAGE - - /* Version of package. */ - #undef VERSION - - /* Whether utime.h defines struct utimbuf. */ - #undef HAVE_STRUCT_UTIMBUF - - -File: configure.info, Node: Generate Files in Example, Prev: Getting Started Example 3, Up: Getting Started Example - -2.5.4 Generate Files --------------------- - -We must now generate the other files, using the following commands. - - aclocal - autoconf - autoheader - automake - - When we run `autoheader', it will remind us of any macros we forgot -to add to `acconfig.h'. - - When we run `automake', it will want to add some files to our -distribution. It will add them automatically if we use the -`--add-missing' option. - - By default, `automake' will run in GNU mode, which means that it -will want us to create certain additional files; as of this writing, it -will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which -are files which should appear in a standard GNU distribution. We can -either add those files, or run `automake' with the `--foreign' option. - - Running these tools will generate the following files, all of which -are described in the next chapter. - - * `aclocal.m4' - - * `configure' - - * `config.in' - - * `Makefile.in' - - * `stamp-h.in' - - -File: configure.info, Node: Files, Next: Configuration Names, Prev: Getting Started, Up: Top - -3 Files -******* - -As was seen in the previous chapter, the GNU configure and build system -uses a number of different files. The developer must write a few files. -The others are generated by various tools. - - The system is rather flexible, and can be used in many different -ways. In describing the files that it uses, I will describe the common -case, and mention some other cases that may arise. - -* Menu: - -* Developer Files:: Developer Files. -* Build Files:: Build Files. -* Support Files:: Support Files. - - -File: configure.info, Node: Developer Files, Next: Build Files, Up: Files - -3.1 Developer Files -=================== - -This section describes the files written or generated by the developer -of a package. - -* Menu: - -* Developer Files Picture:: Developer Files Picture. -* Written Developer Files:: Written Developer Files. -* Generated Developer Files:: Generated Developer Files. - - -File: configure.info, Node: Developer Files Picture, Next: Written Developer Files, Up: Developer Files - -3.1.1 Developer Files Picture ------------------------------ - -Here is a picture of the files which are written by the developer, the -generated files which would be included with a complete source -distribution, and the tools which create those files. The file names -are plain text and the tool names are enclosed by `*' characters (e.g., -`autoheader' is the name of a tool, not the name of a file). - - acconfig.h configure.in Makefile.am - | | | - | --------------+---------------------- | - | | | | | - v v | acinclude.m4 | | - *autoheader* | | v v - | | v --->*automake* - v |--->*aclocal* | | - config.in | | | v - | v | Makefile.in - | aclocal.m4--- - | | - v v - *autoconf* - | - v - configure - - -File: configure.info, Node: Written Developer Files, Next: Generated Developer Files, Prev: Developer Files Picture, Up: Developer Files - -3.1.2 Written Developer Files ------------------------------ - -The following files would be written by the developer. - -`configure.in' - This is the configuration script. This script contains - invocations of autoconf macros. It may also contain ordinary - shell script code. This file will contain feature tests for - portability issues. The last thing in the file will normally be - an `AC_OUTPUT' macro listing which files to create when the - builder runs the configure script. This file is always required - when using the GNU configure system. *Note Write configure.in::. - -`Makefile.am' - This is the automake input file. It describes how the code should - be built. It consists of definitions of automake variables. It - may also contain ordinary Makefile targets. This file is only - needed when using automake (newer tools normally use automake, but - there are still older tools which have not been converted, in - which the developer writes `Makefile.in' directly). *Note Write - Makefile.am::. - -`acconfig.h' - When the configure script creates a portability header file, by - using `AM_CONFIG_HEADER' (or, if not using automake, - `AC_CONFIG_HEADER'), this file is used to describe macros which are - not recognized by the `autoheader' command. This is normally a - fairly uninteresting file, consisting of a collection of `#undef' - lines with comments. Normally any call to `AC_DEFINE' in - `configure.in' will require a line in this file. *Note Write - acconfig.h::. - -`acinclude.m4' - This file is not always required. It defines local autoconf - macros. These macros may then be used in `configure.in'. If you - don't need any local autoconf macros, then you don't need this - file at all. In fact, in general, you never need local autoconf - macros, since you can put everything in `configure.in', but - sometimes a local macro is convenient. - - Newer tools may omit `acinclude.m4', and instead use a - subdirectory, typically named `m4', and define `ACLOCAL_AMFLAGS = - -I m4' in `Makefile.am' to force `aclocal' to look there for macro - definitions. The macro definitions are then placed in separate - files in that directory. - - The `acinclude.m4' file is only used when using automake; in older - tools, the developer writes `aclocal.m4' directly, if it is needed. - - -File: configure.info, Node: Generated Developer Files, Prev: Written Developer Files, Up: Developer Files - -3.1.3 Generated Developer Files -------------------------------- - -The following files would be generated by the developer. - - When using automake, these files are normally not generated manually -after the first time. Instead, the generated `Makefile' contains rules -to automatically rebuild the files as required. When -`AM_MAINTAINER_MODE' is used in `configure.in' (the normal case in -Cygnus code), the automatic rebuilding rules will only be defined if -you configure using the `--enable-maintainer-mode' option. - - When using automatic rebuilding, it is important to ensure that all -the various tools have been built and installed on your `PATH'. Using -automatic rebuilding is highly recommended, so much so that I'm not -going to explain what you have to do if you don't use it. - -`configure' - This is the configure script which will be run when building the - package. This is generated by `autoconf' from `configure.in' and - `aclocal.m4'. This is a shell script. - -`Makefile.in' - This is the file which the configure script will turn into the - `Makefile' at build time. This file is generated by `automake' - from `Makefile.am'. If you aren't using automake, you must write - this file yourself. This file is pretty much a normal `Makefile', - with some configure substitutions for certain variables. - -`aclocal.m4' - This file is created by the `aclocal' program, based on the - contents of `configure.in' and `acinclude.m4' (or, as noted in the - description of `acinclude.m4' above, on the contents of an `m4' - subdirectory). This file contains definitions of autoconf macros - which `autoconf' will use when generating the file `configure'. - These autoconf macros may be defined by you in `acinclude.m4' or - they may be defined by other packages such as automake, libtool or - gettext. If you aren't using automake, you will normally write - this file yourself; in that case, if `configure.in' uses only - standard autoconf macros, this file will not be needed at all. - -`config.in' - This file is created by `autoheader' based on `acconfig.h' and - `configure.in'. At build time, the configure script will define - some of the macros in it to create `config.h', which may then be - included by your program. This permits your C code to use - preprocessor conditionals to change its behaviour based on the - characteristics of the host system. This file may also be called - `config.h.in'. - -`stamp.h-in' - This rather uninteresting file, which I omitted from the picture, - is generated by `automake'. It always contains the string - `timestamp'. It is used as a timestamp file indicating whether - `config.in' is up to date. Using a timestamp file means that - `config.in' can be marked as up to date without actually changing - its modification time. This is useful since `config.in' depends - upon `configure.in', but it is easy to change `configure.in' in a - way which does not affect `config.in'. - - -File: configure.info, Node: Build Files, Next: Support Files, Prev: Developer Files, Up: Files - -3.2 Build Files -=============== - -This section describes the files which are created at configure and -build time. These are the files which somebody who builds the package -will see. - - Of course, the developer will also build the package. The -distinction between developer files and build files is not that the -developer does not see the build files, but that somebody who only -builds the package does not have to worry about the developer files. - -* Menu: - -* Build Files Picture:: Build Files Picture. -* Build Files Description:: Build Files Description. - - -File: configure.info, Node: Build Files Picture, Next: Build Files Description, Up: Build Files - -3.2.1 Build Files Picture -------------------------- - -Here is a picture of the files which will be created at build time. -`config.status' is both a created file and a shell script which is run -to create other files, and the picture attempts to show that. - - config.in *configure* Makefile.in - | | | - | v | - | config.status | - | | | - *config.status*<======+==========>*config.status* - | | - v v - config.h Makefile - - -File: configure.info, Node: Build Files Description, Prev: Build Files Picture, Up: Build Files - -3.2.2 Build Files Description ------------------------------ - -This is a description of the files which are created at build time. - -`config.status' - The first step in building a package is to run the `configure' - script. The `configure' script will create the file - `config.status', which is itself a shell script. When you first - run `configure', it will automatically run `config.status'. An - `Makefile' derived from an automake generated `Makefile.in' will - contain rules to automatically run `config.status' again when - necessary to recreate certain files if their inputs change. - -`Makefile' - This is the file which make will read to build the program. The - `config.status' script will transform `Makefile.in' into - `Makefile'. - -`config.h' - This file defines C preprocessor macros which C code can use to - adjust its behaviour on different systems. The `config.status' - script will transform `config.in' into `config.h'. - -`config.cache' - This file did not fit neatly into the picture, and I omitted it. - It is used by the `configure' script to cache results between - runs. This can be an important speedup. If you modify - `configure.in' in such a way that the results of old tests should - change (perhaps you have added a new library to `LDFLAGS'), then - you will have to remove `config.cache' to force the tests to be - rerun. - - The autoconf manual explains how to set up a site specific cache - file. This can speed up running `configure' scripts on your - system. - -`stamp.h' - This file, which I omitted from the picture, is similar to - `stamp-h.in'. It is used as a timestamp file indicating whether - `config.h' is up to date. This is useful since `config.h' depends - upon `config.status', but it is easy for `config.status' to change - in a way which does not affect `config.h'. - - -File: configure.info, Node: Support Files, Prev: Build Files, Up: Files - -3.3 Support Files -================= - -The GNU configure and build system requires several support files to be -included with your distribution. You do not normally need to concern -yourself with these. If you are using the Cygnus tree, most are already -present. Otherwise, they will be installed with your source by -`automake' (with the `--add-missing' option) and `libtoolize'. - - You don't have to put the support files in the top level directory. -You can put them in a subdirectory, and use the `AC_CONFIG_AUX_DIR' -macro in `configure.in' to tell `automake' and the `configure' script -where they are. - - In this section, I describe the support files, so that you can know -what they are and why they are there. - -`ABOUT-NLS' - Added by automake if you are using gettext. This is a - documentation file about the gettext project. - -`ansi2knr.c' - Used by an automake generated `Makefile' if you put `ansi2knr' in - `AUTOMAKE_OPTIONS' in `Makefile.am'. This permits compiling ANSI - C code with a K&R C compiler. - -`ansi2knr.1' - The man page which goes with `ansi2knr.c'. - -`config.guess' - A shell script which determines the configuration name for the - system on which it is run. - -`config.sub' - A shell script which canonicalizes a configuration name entered by - a user. - -`elisp-comp' - Used to compile Emacs LISP files. - -`install-sh' - A shell script which installs a program. This is used if the - configure script can not find an install binary. - -`ltconfig' - Used by libtool. This is a shell script which configures libtool - for the particular system on which it is used. - -`ltmain.sh' - Used by libtool. This is the actual libtool script which is used, - after it is configured by `ltconfig' to build a library. - -`mdate-sh' - A shell script used by an automake generated `Makefile' to pretty - print the modification time of a file. This is used to maintain - version numbers for texinfo files. - -`missing' - A shell script used if some tool is missing entirely. This is - used by an automake generated `Makefile' to avoid certain sorts of - timestamp problems. - -`mkinstalldirs' - A shell script which creates a directory, including all parent - directories. This is used by an automake generated `Makefile' - during installation. - -`texinfo.tex' - Required if you have any texinfo files. This is used when - converting Texinfo files into DVI using `texi2dvi' and TeX. - -`ylwrap' - A shell script used by an automake generated `Makefile' to run - programs like `bison', `yacc', `flex', and `lex'. These programs - default to producing output files with a fixed name, and the - `ylwrap' script runs them in a subdirectory to avoid file name - conflicts when using a parallel make program. - - -File: configure.info, Node: Configuration Names, Next: Cross Compilation Tools, Prev: Files, Up: Top - -4 Configuration Names -********************* - -The GNU configure system names all systems using a "configuration -name". All such names used to be triplets (they may now contain four -parts in certain cases), and the term "configuration triplet" is still -seen. - -* Menu: - -* Configuration Name Definition:: Configuration Name Definition. -* Using Configuration Names:: Using Configuration Names. - - -File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names - -4.1 Configuration Name Definition -================================= - -This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In -some cases, this is extended to a four part form: -CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM. - - When using a configuration name in a configure option, it is normally -not necessary to specify an entire name. In particular, the -MANUFACTURER field is often omitted, leading to strings such as -`i386-linux' or `sparc-sunos'. The shell script `config.sub' will -translate these shortened strings into the canonical form. autoconf -will arrange for `config.sub' to be run automatically when it is needed. - - The fields of a configuration name are as follows: - -CPU - The type of processor. This is typically something like `i386' or - `sparc'. More specific variants are used as well, such as - `mipsel' to indicate a little endian MIPS processor. - -MANUFACTURER - A somewhat freeform field which indicates the manufacturer of the - system. This is often simply `unknown'. Other common strings are - `pc' for an IBM PC compatible system, or the name of a workstation - vendor, such as `sun'. - -OPERATING_SYSTEM - The name of the operating system which is run on the system. This - will be something like `solaris2.5' or `irix6.3'. There is no - particular restriction on the version number, and strings like - `aix4.1.4.0' are seen. For an embedded system, which has no - operating system, this field normally indicates the type of object - file format, such as `elf' or `coff'. - -KERNEL - This is used mainly for GNU/Linux. A typical GNU/Linux - configuration name is `i586-pc-linux-gnulibc1'. In this case the - kernel, `linux', is separated from the operating system, - `gnulibc1'. - - The shell script `config.guess' will normally print the correct -configuration name for the system on which it is run. It does by -running `uname' and by examining other characteristics of the system. - - Because `config.guess' can normally determine the configuration name -for a machine, it is normally only necessary to specify a configuration -name when building a cross-compiler or when building using a -cross-compiler. - - -File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names - -4.2 Using Configuration Names -============================= - -A configure script will sometimes have to make a decision based on a -configuration name. You will need to do this if you have to compile -code differently based on something which can not be tested using a -standard autoconf feature test. - - It is normally better to test for particular features, rather than to -test for a particular system. This is because as Unix evolves, -different systems copy features from one another. Even if you need to -determine whether the feature is supported based on a configuration -name, you should define a macro which describes the feature, rather than -defining a macro which describes the particular system you are on. - - Testing for a particular system is normally done using a case -statement in `configure.in'. The case statement might look something -like the following, assuming that `host' is a shell variable holding a -canonical configuration name (which will be the case if `configure.in' -uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro). - - case "${host}" in - i[3-7]86-*-linux-gnu*) do something ;; - sparc*-sun-solaris2.[56789]*) do something ;; - sparc*-sun-solaris*) do something ;; - mips*-*-elf*) do something ;; - esac - - It is particularly important to use `*' after the operating system -field, in order to match the version number which will be generated by -`config.guess'. - - In most cases you must be careful to match a range of processor -types. For most processor families, a trailing `*' suffices, as in -`mips*' above. For the i386 family, something along the lines of -`i[3-7]86' suffices at present. For the m68k family, you will need -something like `m68*'. Of course, if you do not need to match on the -processor, it is simpler to just replace the entire field by a `*', as -in `*-*-irix*'. - - -File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top - -5 Cross Compilation Tools -************************* - -The GNU configure and build system can be used to build "cross -compilation" tools. A cross compilation tool is a tool which runs on -one system and produces code which runs on another system. - -* Menu: - -* Cross Compilation Concepts:: Cross Compilation Concepts. -* Host and Target:: Host and Target. -* Using the Host Type:: Using the Host Type. -* Specifying the Target:: Specifying the Target. -* Using the Target Type:: Using the Target Type. -* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree - - -File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools - -5.1 Cross Compilation Concepts -============================== - -A compiler which produces programs which run on a different system is a -cross compilation compiler, or simply a "cross compiler". Similarly, -we speak of cross assemblers, cross linkers, etc. - - In the normal case, a compiler produces code which runs on the same -system as the one on which the compiler runs. When it is necessary to -distinguish this case from the cross compilation case, such a compiler -is called a "native compiler". Similarly, we speak of native -assemblers, etc. - - Although the debugger is not strictly speaking a compilation tool, -it is nevertheless meaningful to speak of a cross debugger: a debugger -which is used to debug code which runs on another system. Everything -that is said below about configuring cross compilation tools applies to -the debugger as well. - - -File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools - -5.2 Host and Target -=================== - -When building cross compilation tools, there are two different systems -involved: the system on which the tools will run, and the system for -which the tools generate code. - - The system on which the tools will run is called the "host" system. - - The system for which the tools generate code is called the "target" -system. - - For example, suppose you have a compiler which runs on a GNU/Linux -system and generates ELF programs for a MIPS embedded system. In this -case the GNU/Linux system is the host, and the MIPS ELF system is the -target. Such a compiler could be called a GNU/Linux cross MIPS ELF -compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf' -compiler. - - Naturally, most programs are not cross compilation tools. For those -programs, it does not make sense to speak of a target. It only makes -sense to speak of a target for tools like `gcc' or the `binutils' which -actually produce running code. For example, it does not make sense to -speak of the target of a tool like `bison' or `make'. - - Most cross compilation tools can also serve as native tools. For a -native compilation tool, it is still meaningful to speak of a target. -For a native tool, the target is the same as the host. For example, for -a GNU/Linux native compiler, the host is GNU/Linux, and the target is -also GNU/Linux. - - -File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools - -5.3 Using the Host Type -======================= - -In almost all cases the host system is the system on which you run the -`configure' script, and on which you build the tools (for the case when -they differ, *note Canadian Cross::). - - If your configure script needs to know the configuration name of the -host system, and the package is not a cross compilation tool and -therefore does not have a target, put `AC_CANONICAL_HOST' in -`configure.in'. This macro will arrange to define a few shell -variables when the `configure' script is run. - -`host' - The canonical configuration name of the host. This will normally - be determined by running the `config.guess' shell script, although - the user is permitted to override this by using an explicit - `--host' option. - -`host_alias' - In the unusual case that the user used an explicit `--host' option, - this will be the argument to `--host'. In the normal case, this - will be the same as the `host' variable. - -`host_cpu' -`host_vendor' -`host_os' - The first three parts of the canonical configuration name. - - The shell variables may be used by putting shell code in -`configure.in'. For an example, see *Note Using Configuration Names::. - - -File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools - -5.4 Specifying the Target -========================= - -By default, the `configure' script will assume that the target is the -same as the host. This is the more common case; for example, it leads -to a native compiler rather than a cross compiler. - - If you want to build a cross compilation tool, you must specify the -target explicitly by using the `--target' option when you run -`configure'. The argument to `--target' is the configuration name of -the system for which you wish to generate code. *Note Configuration -Names::. - - For example, to build tools which generate code for a MIPS ELF -embedded system, you would use `--target mips-elf'. - - -File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools - -5.5 Using the Target Type -========================= - -When writing `configure.in' for a cross compilation tool, you will need -to use information about the target. To do this, put -`AC_CANONICAL_SYSTEM' in `configure.in'. - - `AC_CANONICAL_SYSTEM' will look for a `--target' option and -canonicalize it using the `config.sub' shell script. It will also run -`AC_CANONICAL_HOST' (*note Using the Host Type::). - - The target type will be recorded in the following shell variables. -Note that the host versions of these variables will also be defined by -`AC_CANONICAL_HOST'. - -`target' - The canonical configuration name of the target. - -`target_alias' - The argument to the `--target' option. If the user did not specify - a `--target' option, this will be the same as `host_alias'. - -`target_cpu' -`target_vendor' -`target_os' - The first three parts of the canonical target configuration name. - - Note that if `host' and `target' are the same string, you can assume -a native configuration. If they are different, you can assume a cross -configuration. - - It is arguably possible for `host' and `target' to represent the -same system, but for the strings to not be identical. For example, if -`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures -with `--target sparc-sun-sunos4.1', then the slight differences between -the two versions of SunOS may be unimportant for your tool. However, -in the general case it can be quite difficult to determine whether the -differences between two configuration names are significant or not. -Therefore, by convention, if the user specifies a `--target' option -without specifying a `--host' option, it is assumed that the user wants -to configure a cross compilation tool. - - The variables `target' and `target_alias' should be handled -differently. - - In general, whenever the user may actually see a string, -`target_alias' should be used. This includes anything which may appear -in the file system, such as a directory name or part of a tool name. -It also includes any tool output, unless it is clearly labelled as the -canonical target configuration name. This permits the user to use the -`--target' option to specify how the tool will appear to the outside -world. - - On the other hand, when checking for characteristics of the target -system, `target' should be used. This is because a wide variety of -`--target' options may map into the same canonical configuration name. -You should not attempt to duplicate the canonicalization done by -`config.sub' in your own code. - - By convention, cross tools are installed with a prefix of the -argument used with the `--target' option, also known as `target_alias' -(*note Using the Target Type::). If the user does not use the -`--target' option, and thus is building a native tool, no prefix is -used. - - For example, if gcc is configured with `--target mips-elf', then the -installed binary will be named `mips-elf-gcc'. If gcc is configured -without a `--target' option, then the installed binary will be named -`gcc'. - - The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If -you are using automake, no more need be done; the programs will -automatically be installed with the correct prefixes. Otherwise, see -the autoconf documentation for `AC_ARG_PROGRAM'. - - -File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools - -5.6 Cross Tools in the Cygnus Tree -================================== - -The Cygnus tree is used for various packages including gdb, the GNU -binutils, and egcs. It is also, of course, used for Cygnus releases. - - In the Cygnus tree, the top level `configure' script uses the old -Cygnus configure system, not autoconf. The top level `Makefile.in' is -written to build packages based on what is in the source tree, and -supports building a large number of tools in a single -`configure'/`make' step. - - The Cygnus tree may be configured with a `--target' option. The -`--target' option applies recursively to every subdirectory, and -permits building an entire set of cross tools at once. - -* Menu: - -* Host and Target Libraries:: Host and Target Libraries. -* Target Library Configure Scripts:: Target Library Configure Scripts. -* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree. -* Target libiberty:: Target libiberty - - -File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree - -5.6.1 Host and Target Libraries -------------------------------- - -The Cygnus tree distinguishes host libraries from target libraries. - - Host libraries are built with the compiler used to build the programs -which run on the host, which is called the host compiler. This includes -libraries such as `bfd' and `tcl'. These libraries are built with the -host compiler, and are linked into programs like the binutils or gcc -which run on the host. - - Target libraries are built with the target compiler. If gcc is -present in the source tree, then the target compiler is the gcc that is -built using the host compiler. Target libraries are libraries such as -`newlib' and `libstdc++'. These libraries are not linked into the host -programs, but are instead made available for use with programs built -with the target compiler. - - For the rest of this section, assume that gcc is present in the -source tree, so that it will be used to build the target libraries. - - There is a complication here. The configure process needs to know -which compiler you are going to use to build a tool; otherwise, the -feature tests will not work correctly. The Cygnus tree handles this by -not configuring the target libraries until the target compiler is -built. In order to permit everything to build using a single -`configure'/`make', the configuration of the target libraries is -actually triggered during the make step. - - When the target libraries are configured, the `--target' option is -not used. Instead, the `--host' option is used with the argument of -the `--target' option for the overall configuration. If no `--target' -option was used for the overall configuration, the `--host' option will -be passed with the output of the `config.guess' shell script. Any -`--build' option is passed down unchanged. - - This translation of configuration options is done because since the -target libraries are compiled with the target compiler, they are being -built in order to run on the target of the overall configuration. By -the definition of host, this means that their host system is the same as -the target system of the overall configuration. - - The same process is used for both a native configuration and a cross -configuration. Even when using a native configuration, the target -libraries will be configured and built using the newly built compiler. -This is particularly important for the C++ libraries, since there is no -reason to assume that the C++ compiler used to build the host tools (if -there even is one) uses the same ABI as the g++ compiler which will be -used to build the target libraries. - - There is one difference between a native configuration and a cross -configuration. In a native configuration, the target libraries are -normally configured and built as siblings of the host tools. In a cross -configuration, the target libraries are normally built in a subdirectory -whose name is the argument to `--target'. This is mainly for -historical reasons. - - To summarize, running `configure' in the Cygnus tree configures all -the host libraries and tools, but does not configure any of the target -libraries. Running `make' then does the following steps: - - * Build the host libraries. - - * Build the host programs, including gcc. Note that we call gcc - both a host program (since it runs on the host) and a target - compiler (since it generates code for the target). - - * Using the newly built target compiler, configure the target - libraries. - - * Build the target libraries. - - The steps need not be done in precisely this order, since they are -actually controlled by `Makefile' targets. - - -File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree - -5.6.2 Target Library Configure Scripts --------------------------------------- - -There are a few things you must know in order to write a configure -script for a target library. This is just a quick sketch, and beginners -shouldn't worry if they don't follow everything here. - - The target libraries are configured and built using a newly built -target compiler. There may not be any startup files or libraries for -this target compiler. In fact, those files will probably be built as -part of some target library, which naturally means that they will not -exist when your target library is configured. - - This means that the configure script for a target library may not use -any test which requires doing a link. This unfortunately includes many -useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros -which do a compile but not a link, such as `AC_CHECK_HEADERS', may be -used. - - This is a severe restriction, but normally not a fatal one, as target -libraries can often assume the presence of other target libraries, and -thus know which functions will be available. - - As of this writing, the autoconf macro `AC_PROG_CC' does a link to -make sure that the compiler works. This may fail in a target library, -so target libraries must use a different set of macros to locate the -compiler. See the `configure.in' file in a directory like `libiberty' -or `libgloss' for an example. - - As noted in the previous section, target libraries are sometimes -built in directories which are siblings to the host tools, and are -sometimes built in a subdirectory. The `--with-target-subdir' configure -option will be passed when the library is configured. Its value will be -an empty string if the target library is a sibling. Its value will be -the name of the subdirectory if the target library is in a subdirectory. - - If the overall build is not a native build (i.e., the overall -configure used the `--target' option), then the library will be -configured with the `--with-cross-host' option. The value of this -option will be the host system of the overall build. Recall that the -host system of the library will be the target of the overall build. If -the overall build is a native build, the `--with-cross-host' option -will not be used. - - A library which can be built both standalone and as a target library -may want to install itself into different directories depending upon the -case. When built standalone, or when built native, the library should -be installed in `$(libdir)'. When built as a target library which is -not native, the library should be installed in `$(tooldir)/lib'. The -`--with-cross-host' option may be used to distinguish these cases. - - This same test of `--with-cross-host' may be used to see whether it -is OK to use link tests in the configure script. If the -`--with-cross-host' option is not used, then the library is being built -either standalone or native, and a link should work. - - -File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree - -5.6.3 Make Targets in Cygnus Tree ---------------------------------- - -The top level `Makefile' in the Cygnus tree defines targets for every -known subdirectory. - - For every subdirectory DIR which holds a host library or program, -the `Makefile' target `all-DIR' will build that library or program. - - There are dependencies among host tools. For example, building gcc -requires first building gas, because the gcc build process invokes the -target assembler. These dependencies are reflected in the top level -`Makefile'. - - For every subdirectory DIR which holds a target library, the -`Makefile' target `configure-target-DIR' will configure that library. -The `Makefile' target `all-target-DIR' will build that library. - - Every `configure-target-DIR' target depends upon `all-gcc', since -gcc, the target compiler, is required to configure the tool. Every -`all-target-DIR' target depends upon the corresponding -`configure-target-DIR' target. - - There are several other targets which may be of interest for each -directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also -corresponding `target' versions of these for the target libraries , -such as `install-target-DIR'. - - -File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree - -5.6.4 Target libiberty ----------------------- - -The `libiberty' subdirectory is currently a special case, in that it is -the only directory which is built both using the host compiler and -using the target compiler. - - This is because the files in `libiberty' are used when building the -host tools, and they are also incorporated into the `libstdc++' target -library as support code. - - This duality does not pose any particular difficulties. It means -that there are targets for both `all-libiberty' and -`all-target-libiberty'. - - In a native configuration, when target libraries are not built in a -subdirectory, the same objects are normally used as both the host build -and the target build. This is normally OK, since libiberty contains -only C code, and in a native configuration the results of the host -compiler and the target compiler are normally interoperable. - - Irix 6 is again an exception here, since the SGI native compiler -defaults to using the `O32' ABI, and gcc defaults to using the `N32' -ABI. On Irix 6, the target libraries are built in a subdirectory even -for a native configuration, avoiding this problem. - - There are currently no other libraries built for both the host and -the target, but there is no conceptual problem with adding more. - - -File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top - -6 Canadian Cross -**************** - -It is possible to use the GNU configure and build system to build a -program which will run on a system which is different from the system on -which the tools are built. In other words, it is possible to build -programs using a cross compiler. - - This is referred to as a "Canadian Cross". - -* Menu: - -* Canadian Cross Example:: Canadian Cross Example. -* Canadian Cross Concepts:: Canadian Cross Concepts. -* Build Cross Host Tools:: Build Cross Host Tools. -* Build and Host Options:: Build and Host Options. -* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree. -* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree. -* Supporting Canadian Cross:: Supporting Canadian Cross. - - -File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross - -6.1 Canadian Cross Example -========================== - -Here is an example of a Canadian Cross. - - While running on a GNU/Linux, you can build a program which will run -on a Solaris system. You would use a GNU/Linux cross Solaris compiler -to build the program. - - Of course, you could not run the resulting program on your GNU/Linux -system. You would have to copy it over to a Solaris system before you -would run it. - - Of course, you could also simply build the programs on the Solaris -system in the first place. However, perhaps the Solaris system is not -available for some reason; perhaps you actually don't have one, but you -want to build the tools for somebody else to use. Or perhaps your -GNU/Linux system is much faster than your Solaris system. - - A Canadian Cross build is most frequently used when building -programs to run on a non-Unix system, such as DOS or Windows. It may -be simpler to configure and build on a Unix system than to support the -configuration machinery on a non-Unix system. - - -File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross - -6.2 Canadian Cross Concepts -=========================== - -When building a Canadian Cross, there are at least two different systems -involved: the system on which the tools are being built, and the system -on which the tools will run. - - The system on which the tools are being built is called the "build" -system. - - The system on which the tools will run is called the host system. - - For example, if you are building a Solaris program on a GNU/Linux -system, as in the previous section, the build system would be GNU/Linux, -and the host system would be Solaris. - - It is, of course, possible to build a cross compiler using a Canadian -Cross (i.e., build a cross compiler using a cross compiler). In this -case, the system for which the resulting cross compiler generates code -is called the target system. (For a more complete discussion of host -and target systems, *note Host and Target::). - - An example of building a cross compiler using a Canadian Cross would -be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In -this case the build system would be GNU/Linux, the host system would be -Windows, and the target system would be MIPS ELF. - - The name Canadian Cross comes from the case when the build, host, and -target systems are all different. At the time that these issues were -all being hashed out, Canada had three national political parties. - - -File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross - -6.3 Build Cross Host Tools -========================== - -In order to configure a program for a Canadian Cross build, you must -first build and install the set of cross tools you will use to build the -program. - - These tools will be build cross host tools. That is, they will run -on the build system, and will produce code that runs on the host system. - - It is easy to confuse the meaning of build and host here. Always -remember that the build system is where you are doing the build, and the -host system is where the resulting program will run. Therefore, you -need a build cross host compiler. - - In general, you must have a complete cross environment in order to do -the build. This normally means a cross compiler, cross assembler, and -so forth, as well as libraries and include files for the host system. - - -File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross - -6.4 Build and Host Options -========================== - -When you run `configure', you must use both the `--build' and `--host' -options. - - The `--build' option is used to specify the configuration name of -the build system. This can normally be the result of running the -`config.guess' shell script, and it is reasonable to use -`--build=`config.guess`'. - - The `--host' option is used to specify the configuration name of the -host system. - - As we explained earlier, `config.guess' is used to set the default -value for the `--host' option (*note Using the Host Type::). We can -now see that since `config.guess' returns the type of system on which -it is run, it really identifies the build system. Since the host -system is normally the same as the build system (i.e., people do not -normally build using a cross compiler), it is reasonable to use the -result of `config.guess' as the default for the host system when the -`--host' option is not used. - - It might seem that if the `--host' option were used without the -`--build' option that the configure script could run `config.guess' to -determine the build system, and presume a Canadian Cross if the result -of `config.guess' differed from the `--host' option. However, for -historical reasons, some configure scripts are routinely run using an -explicit `--host' option, rather than using the default from -`config.guess'. As noted earlier, it is difficult or impossible to -reliably compare configuration names (*note Using the Target Type::). -Therefore, by convention, if the `--host' option is used, but the -`--build' option is not used, then the build system defaults to the -host system. - - -File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross - -6.5 Canadian Cross not in Cygnus Tree. -====================================== - -If you are not using the Cygnus tree, you must explicitly specify the -cross tools which you want to use to build the program. This is done by -setting environment variables before running the `configure' script. - - You must normally set at least the environment variables `CC', `AR', -and `RANLIB' to the cross tools which you want to use to build. - - For some programs, you must set additional cross tools as well, such -as `AS', `LD', or `NM'. - - You would set these environment variables to the build cross tools -which you are going to use. - - For example, if you are building a Solaris program on a GNU/Linux -system, and your GNU/Linux cross Solaris compiler were named -`solaris-gcc', then you would set the environment variable `CC' to -`solaris-gcc'. - - -File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross - -6.6 Canadian Cross in Cygnus Tree -================================= - -This section describes configuring and building a Canadian Cross when -using the Cygnus tree. - -* Menu: - -* Standard Cygnus CCross:: Building a Normal Program. -* Cross Cygnus CCross:: Building a Cross Program. - - -File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree - -6.6.1 Building a Normal Program -------------------------------- - -When configuring a Canadian Cross in the Cygnus tree, all the -appropriate environment variables are automatically set to `HOST-TOOL', -where HOST is the value used for the `--host' option, and TOOL is the -name of the tool (e.g., `gcc', `as', etc.). These tools must be on -your `PATH'. - - Adding a prefix of HOST will give the usual name for the build cross -host tools. To see this, consider that when these cross tools were -built, they were configured to run on the build system and to produce -code for the host system. That is, they were configured with a -`--target' option that is the same as the system which we are now -calling the host. Recall that the default name for installed cross -tools uses the target system as a prefix (*note Using the Target -Type::). Since that is the system which we are now calling the host, -HOST is the right prefix to use. - - For example, if you configure with `--build=i386-linux-gnu' and -`--host=solaris', then the Cygnus tree will automatically default to -using the compiler `solaris-gcc'. You must have previously built and -installed this compiler, probably by doing a build with no `--host' -option and with a `--target' option of `solaris'. - - -File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree - -6.6.2 Building a Cross Program ------------------------------- - -There are additional considerations if you want to build a cross -compiler, rather than a native compiler, in the Cygnus tree using a -Canadian Cross. - - When you build a cross compiler using the Cygnus tree, then the -target libraries will normally be built with the newly built target -compiler (*note Host and Target Libraries::). However, this will not -work when building with a Canadian Cross. This is because the newly -built target compiler will be a program which runs on the host system, -and therefore will not be able to run on the build system. - - Therefore, when building a cross compiler with the Cygnus tree, you -must first install a set of build cross target tools. These tools will -be used when building the target libraries. - - Note that this is not a requirement of a Canadian Cross in general. -For example, it would be possible to build just the host cross target -tools on the build system, to copy the tools to the host system, and to -build the target libraries on the host system. The requirement for -build cross target tools is imposed by the Cygnus tree, which expects -to be able to build both host programs and target libraries in a single -`configure'/`make' step. Because it builds these in a single step, it -expects to be able to build the target libraries on the build system, -which means that it must use a build cross target toolchain. - - For example, suppose you want to build a Windows cross MIPS ELF -compiler on a GNU/Linux system. You must have previously installed -both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF -compiler. - - In order to build the Windows (configuration name `i386-cygwin32') -cross MIPS ELF (configure name `mips-elf') compiler, you might execute -the following commands (long command lines are broken across lines with -a trailing backslash as a continuation character). - - mkdir linux-x-cygwin32 - cd linux-x-cygwin32 - SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \ - --exec-prefix=INSTALLDIR/H-i386-linux - make - make install - cd .. - mkdir linux-x-mips-elf - cd linux-x-mips-elf - SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \ - --exec-prefix=INSTALLDIR/H-i386-linux - make - make install - cd .. - mkdir cygwin32-x-mips-elf - cd cygwin32-x-mips-elf - SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \ - --target=mips-elf --prefix=WININSTALLDIR \ - --exec-prefix=WININSTALLDIR/H-i386-cygwin32 - make - make install - - You would then copy the contents of WININSTALLDIR over to the -Windows machine, and run the resulting programs. - - -File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross - -6.7 Supporting Canadian Cross -============================= - -If you want to make it possible to build a program you are developing -using a Canadian Cross, you must take some care when writing your -configure and make rules. Simple cases will normally work correctly. -However, it is not hard to write configure and make tests which will -fail in a Canadian Cross. - -* Menu: - -* CCross in Configure:: Supporting Canadian Cross in Configure Scripts. -* CCross in Make:: Supporting Canadian Cross in Makefiles. - - -File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross - -6.7.1 Supporting Canadian Cross in Configure Scripts ----------------------------------------------------- - -In a `configure.in' file, after calling `AC_PROG_CC', you can find out -whether this is a Canadian Cross configure by examining the shell -variable `cross_compiling'. In a Canadian Cross, which means that the -compiler is a cross compiler, `cross_compiling' will be `yes'. In a -normal configuration, `cross_compiling' will be `no'. - - You ordinarily do not need to know the type of the build system in a -configure script. However, if you do need that information, you can get -it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is -used to determine the target system. This macro will set the variables -`build', `build_alias', `build_cpu', `build_vendor', and `build_os', -which correspond to the similar `target' and `host' variables, except -that they describe the build system. - - When writing tests in `configure.in', you must remember that you -want to test the host environment, not the build environment. - - Macros like `AC_CHECK_FUNCS' which use the compiler will test the -host environment. That is because the tests will be done by running the -compiler, which is actually a build cross host compiler. If the -compiler can find the function, that means that the function is present -in the host environment. - - Tests like `test -f /dev/ptyp0', on the other hand, will test the -build environment. Remember that the configure script is running on the -build system, not the host system. If your configure scripts examines -files, those files will be on the build system. Whatever you determine -based on those files may or may not be the case on the host system. - - Most autoconf macros will work correctly for a Canadian Cross. The -main exception is `AC_TRY_RUN'. This macro tries to compile and run a -test program. This will fail in a Canadian Cross, because the program -will be compiled for the host system, which means that it will not run -on the build system. - - The `AC_TRY_RUN' macro provides an optional argument to tell the -configure script what to do in a Canadian Cross. If that argument is -not present, you will get a warning when you run `autoconf': - warning: AC_TRY_RUN called without default to allow cross compiling - This tells you that the resulting `configure' script will not work -with a Canadian Cross. - - In some cases while it may better to perform a test at configure -time, it is also possible to perform the test at run time. In such a -case you can use the cross compiling argument to `AC_TRY_RUN' to tell -your program that the test could not be performed at configure time. - - There are a few other autoconf macros which will not work correctly -with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP', -`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and -`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is -generally not very useful with a Canadian Cross; it permits an optional -argument indicating the default size, but there is no way to know what -the correct default should be. - - -File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross - -6.7.2 Supporting Canadian Cross in Makefiles. ---------------------------------------------- - -The main Canadian Cross issue in a `Makefile' arises when you want to -use a subsidiary program to generate code or data which you will then -include in your real program. - - If you compile this subsidiary program using `$(CC)' in the usual -way, you will not be able to run it. This is because `$(CC)' will -build a program for the host system, but the program is being built on -the build system. - - You must instead use a compiler for the build system, rather than the -host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)' -will hold a compiler for the build system. - - Note that you should not include `config.h' in a file you are -compiling with `$(CC_FOR_BUILD)'. The `configure' script will build -`config.h' with information for the host system. However, you are -compiling the file using a compiler for the build system (a native -compiler). Subsidiary programs are normally simple filters which do no -user interaction, and it is normally possible to write them in a highly -portable fashion so that the absence of `config.h' is not crucial. - - The gcc `Makefile.in' shows a complex situation in which certain -files, such as `rtl.c', must be compiled into both subsidiary programs -run on the build system and into the final program. This approach may -be of interest for advanced build system hackers. Note that the build -system compiler is rather confusingly called `HOST_CC'. - - -File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top - -7 Cygnus Configure -****************** - -The Cygnus configure script predates autoconf. All of its interesting -features have been incorporated into autoconf. No new programs should -be written to use the Cygnus configure script. - - However, the Cygnus configure script is still used in a few places: -at the top of the Cygnus tree and in a few target libraries in the -Cygnus tree. Until those uses have been replaced with autoconf, some -brief notes are appropriate here. This is not complete documentation, -but it should be possible to use this as a guide while examining the -scripts themselves. - -* Menu: - -* Cygnus Configure Basics:: Cygnus Configure Basics. -* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries. - - -File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure - -7.1 Cygnus Configure Basics -=========================== - -Cygnus configure does not use any generated files; there is no program -corresponding to `autoconf'. Instead, there is a single shell script -named `configure' which may be found at the top of the Cygnus tree. -This shell script was written by hand; it was not generated by -autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in -the top level of a Cygnus tree. - - Cygnus configure works in a particular directory by examining the -file `configure.in' in that directory. That file is broken into four -separate shell scripts. - - The first is the contents of `configure.in' up to a line that starts -with `# per-host:'. This is the common part. - - The second is the rest of `configure.in' up to a line that starts -with `# per-target:'. This is the per host part. - - The third is the rest of `configure.in' up to a line that starts -with `# post-target:'. This is the per target part. - - The fourth is the remainder of `configure.in'. This is the post -target part. - - If any of these comment lines are missing, the corresponding shell -script is empty. - - Cygnus configure will first execute the common part. This must set -the shell variable `srctrigger' to the name of a source file, to -confirm that Cygnus configure is looking at the right directory. This -may set the shell variables `package_makefile_frag' and -`package_makefile_rules_frag'. - - Cygnus configure will next set the `build' and `host' shell -variables, and execute the per host part. This may set the shell -variable `host_makefile_frag'. - - Cygnus configure will next set the `target' variable, and execute -the per target part. This may set the shell variable -`target_makefile_frag'. - - Any of these scripts may set the `subdirs' shell variable. This -variable is a list of subdirectories where a `Makefile.in' file may be -found. Cygnus configure will automatically look for a `Makefile.in' -file in the current directory. The `subdirs' shell variable is not -normally used, and I believe that the only directory which uses it at -present is `newlib'. - - For each `Makefile.in', Cygnus configure will automatically create a -`Makefile' by adding definitions for `make' variables such as `host' -and `target', and automatically editing the values of `make' variables -such as `prefix' if they are present. - - Also, if any of the `makefile_frag' shell variables are set, Cygnus -configure will interpret them as file names relative to either the -working directory or the source directory, and will read the contents of -the file into the generated `Makefile'. The file contents will be read -in after the first line in `Makefile.in' which starts with `####'. - - These `Makefile' fragments are used to customize behaviour for a -particular host or target. They serve to select particular files to -compile, and to define particular preprocessor macros by providing -values for `make' variables which are then used during compilation. -Cygnus configure, unlike autoconf, normally does not do feature tests, -and normally requires support to be added manually for each new host. - - The `Makefile' fragment support is similar to the autoconf -`AC_SUBST_FILE' macro. - - After creating each `Makefile', the post target script will be run -(i.e., it may be run several times). This script may further customize -the `Makefile'. When it is run, the shell variable `Makefile' will -hold the name of the `Makefile', including the appropriate directory -component. - - Like an autoconf generated `configure' script, Cygnus configure will -create a file named `config.status' which, when run, will automatically -recreate the configuration. The `config.status' file will simply -execute the Cygnus configure script again with the appropriate -arguments. - - Any of the parts of `configure.in' may set the shell variables -`files' and `links'. Cygnus configure will set up symlinks from the -names in `links' to the files named in `files'. This is similar to the -autoconf `AC_LINK_FILES' macro. - - Finally, any of the parts of `configure.in' may set the shell -variable `configdirs' to a set of subdirectories. If it is set, Cygnus -configure will recursively run the configure process in each -subdirectory. If the subdirectory uses Cygnus configure, it will -contain a `configure.in' file but no `configure' file, in which case -Cygnus configure will invoke itself recursively. If the subdirectory -has a `configure' file, Cygnus configure assumes that it is an autoconf -generated `configure' script, and simply invokes it directly. - - -File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure - -7.2 Cygnus Configure in C++ Libraries -===================================== - -The C++ library configure system, written by Per Bothner, deserves -special mention. It uses Cygnus configure, but it does feature testing -like that done by autoconf generated `configure' scripts. This -approach is used in the libraries `libio', `libstdc++', and `libg++'. - - Most of the `Makefile' information is written out by the shell -script `libio/config.shared'. Each `configure.in' file sets certain -shell variables, and then invokes `config.shared' to create two package -`Makefile' fragments. These fragments are then incorporated into the -resulting `Makefile' by the Cygnus configure script. - - The file `_G_config.h' is created in the `libio' object directory by -running the shell script `libio/gen-params'. This shell script uses -feature tests to define macros and typedefs in `_G_config.h'. - - -File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top - -8 Multilibs -*********** - -For some targets gcc may have different processor requirements depending -upon command line options. An obvious example is the `-msoft-float' -option supported on several processors. This option means that the -floating point registers are not available, which means that floating -point operations must be done by calling an emulation subroutine rather -than by using machine instructions. - - For such options, gcc is often configured to compile target libraries -twice: once with `-msoft-float' and once without. When gcc compiles -target libraries more than once, the resulting libraries are called -"multilibs". - - Multilibs are not really part of the GNU configure and build system, -but we discuss them here since they require support in the `configure' -scripts and `Makefile's used for target libraries. - -* Menu: - -* Multilibs in gcc:: Multilibs in gcc. -* Multilibs in Target Libraries:: Multilibs in Target Libraries. - - -File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs - -8.1 Multilibs in gcc -==================== - -In gcc, multilibs are defined by setting the variable -`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other -`MULTILIB' variables may also be defined there. *Note The Target -Makefile Fragment: (gcc)Target Fragment. - - If you have built gcc, you can see what multilibs it uses by running -it with the `-print-multi-lib' option. The output `.;' means that no -multilibs are used. In general, the output is a sequence of lines, one -per multilib. The first part of each line, up to the `;', is the name -of the multilib directory. The second part is a list of compiler -options separated by `@' characters. - - Multilibs are built in a tree of directories. The top of the tree, -represented by `.' in the list of multilib directories, is the default -library to use when no special compiler options are used. The -subdirectories of the tree hold versions of the library to use when -particular compiler options are used. - - -File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs - -8.2 Multilibs in Target Libraries -================================= - -The target libraries in the Cygnus tree are automatically built with -multilibs. That means that each library is built multiple times. - - This default is set in the top level `configure.in' file, by adding -`--enable-multilib' to the list of arguments passed to configure when -it is run for the target libraries (*note Host and Target Libraries::). - - Each target library uses the shell script `config-ml.in', written by -Doug Evans, to prepare to build target libraries. This shell script is -invoked after the `Makefile' has been created by the `configure' -script. If multilibs are not enabled, it does nothing, otherwise it -modifies the `Makefile' to support multilibs. - - The `config-ml.in' script makes one copy of the `Makefile' for each -multilib in the appropriate subdirectory. When configuring in the -source directory (which is not recommended), it will build a symlink -tree of the sources in each subdirectory. - - The `config-ml.in' script sets several variables in the various -`Makefile's. The `Makefile.in' must have definitions for these -variables already; `config-ml.in' simply changes the existing values. -The `Makefile' should use default values for these variables which will -do the right thing in the subdirectories. - -`MULTISRCTOP' - `config-ml.in' will set this to a sequence of `../' strings, where - the number of strings is the number of multilib levels in the - source tree. The default value should be the empty string. - -`MULTIBUILDTOP' - `config-ml.in' will set this to a sequence of `../' strings, where - the number of strings is number of multilib levels in the object - directory. The default value should be the empty string. This - will differ from `MULTISRCTOP' when configuring in the source tree - (which is not recommended). - -`MULTIDIRS' - In the top level `Makefile' only, `config-ml.in' will set this to - the list of multilib subdirectories. The default value should be - the empty string. - -`MULTISUBDIR' - `config-ml.in' will set this to the installed subdirectory name to - use for this subdirectory, with a leading `/'. The default value - shold be the empty string. - -`MULTIDO' -`MULTICLEAN' - In the top level `Makefile' only, `config-ml.in' will set these - variables to commands to use when doing a recursive make. These - variables should both default to the string `true', so that by - default nothing happens. - - All references to the parent of the source directory should use the -variable `MULTISRCTOP'. Instead of writing `$(srcdir)/..', you must -write `$(srcdir)/$(MULTISRCTOP)..'. - - Similarly, references to the parent of the object directory should -use the variable `MULTIBUILDTOP'. - - In the installation target, the libraries should be installed in the -subdirectory `MULTISUBDIR'. Instead of installing -`$(libdir)/libfoo.a', install `$(libdir)$(MULTISUBDIR)/libfoo.a'. - - The `config-ml.in' script also modifies the top level `Makefile' to -add `multi-do' and `multi-clean' targets which are used when building -multilibs. - - The default target of the `Makefile' should include the following -command: - @$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do - This assumes that `$(FLAGS_TO_PASS)' is defined as a set of -variables to pass to a recursive invocation of `make'. This will build -all the multilibs. Note that the default value of `MULTIDO' is `true', -so by default this command will do nothing. It will only do something -in the top level `Makefile' if multilibs were enabled. - - The `install' target of the `Makefile' should include the following -command: - @$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do - - In general, any operation, other than clean, which should be -performed on all the multilibs should use a `$(MULTIDO)' line, setting -the variable `DO' to the target of each recursive call to `make'. - - The `clean' targets (`clean', `mostlyclean', etc.) should use -`$(MULTICLEAN)'. For example, the `clean' target should do this: - @$(MULTICLEAN) DO=clean multi-clean - - -File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top - -9 Frequently Asked Questions -**************************** - -Which do I run first, `autoconf' or `automake'? - Except when you first add autoconf or automake support to a - package, you shouldn't run either by hand. Instead, configure - with the `--enable-maintainer-mode' option, and let `make' take - care of it. - -`autoconf' says something about undefined macros. - This means that you have macros in your `configure.in' which are - not defined by `autoconf'. You may be using an old version of - `autoconf'; try building and installing a newer one. Make sure the - newly installled `autoconf' is first on your `PATH'. Also, see - the next question. - -My `configure' script has stuff like `CY_GNU_GETTEXT' in it. - This means that you have macros in your `configure.in' which should - be defined in your `aclocal.m4' file, but aren't. This usually - means that `aclocal' was not able to appropriate definitions of the - macros. Make sure that you have installed all the packages you - need. In particular, make sure that you have installed libtool - (this is where `AM_PROG_LIBTOOL' is defined) and gettext (this is - where `CY_GNU_GETTEXT' is defined, at least in the Cygnus version - of gettext). - -My `Makefile' has `@' characters in it. - This may mean that you tried to use an autoconf substitution in - your `Makefile.in' without adding the appropriate `AC_SUBST' call - to your `configure' script. Or it may just mean that you need to - rebuild `Makefile' in your build directory. To rebuild `Makefile' - from `Makefile.in', run the shell script `config.status' with no - arguments. If you need to force `configure' to run again, first - run `config.status --recheck'. These runs are normally done - automatically by `Makefile' targets, but if your `Makefile' has - gotten messed up you'll need to help them along. - -Why do I have to run both `config.status --recheck' and `config.status'? - Normally, you don't; they will be run automatically by `Makefile' - targets. If you do need to run them, use `config.status --recheck' - to run the `configure' script again with the same arguments as the - first time you ran it. Use `config.status' (with no arguments) to - regenerate all files (`Makefile', `config.h', etc.) based on the - results of the configure script. The two cases are separate - because it isn't always necessary to regenerate all the files - after running `config.status --recheck'. The `Makefile' targets - generated by automake will use the environment variables - `CONFIG_FILES' and `CONFIG_HEADERS' to only regenerate files as - they are needed. - -What is the Cygnus tree? - The Cygnus tree is used for various packages including gdb, the GNU - binutils, and egcs. It is also, of course, used for Cygnus - releases. It is the build system which was developed at Cygnus, - using the Cygnus configure script. It permits building many - different packages with a single configure and make. The - configure scripts in the tree are being converted to autoconf, but - the general build structure remains intact. - -Why do I have to keep rebuilding and reinstalling the tools? - I know, it's a pain. Unfortunately, there are bugs in the tools - themselves which need to be fixed, and each time that happens - everybody who uses the tools need to reinstall new versions of - them. I don't know if there is going to be a clever fix until the - tools stabilize. - -Why not just have a Cygnus tree `make' target to update the tools? - The tools unfortunately need to be installed before they can be - used. That means that they must be built using an appropriate - prefix, and it seems unwise to assume that every configuration - uses an appropriate prefix. It might be possible to make them - work in place, or it might be possible to install them in some - subdirectory; so far these approaches have not been implemented. - - -File: configure.info, Node: Index, Prev: FAQ, Up: Top - -Index -***** - - -* Menu: - -* --build option: Build and Host Options. - (line 9) -* --host option: Build and Host Options. - (line 14) -* --target option: Specifying the Target. - (line 10) -* _GNU_SOURCE: Write configure.in. (line 134) -* AC_CANONICAL_HOST: Using the Host Type. (line 10) -* AC_CANONICAL_SYSTEM: Using the Target Type. - (line 6) -* AC_CONFIG_HEADER: Write configure.in. (line 66) -* AC_EXEEXT: Write configure.in. (line 86) -* AC_INIT: Write configure.in. (line 38) -* AC_OUTPUT: Write configure.in. (line 142) -* AC_PREREQ: Write configure.in. (line 42) -* AC_PROG_CC: Write configure.in. (line 103) -* AC_PROG_CXX: Write configure.in. (line 117) -* acconfig.h: Written Developer Files. - (line 27) -* acconfig.h, writing: Write acconfig.h. (line 6) -* acinclude.m4: Written Developer Files. - (line 37) -* aclocal.m4: Generated Developer Files. - (line 33) -* AM_CONFIG_HEADER: Write configure.in. (line 53) -* AM_DISABLE_SHARED: Write configure.in. (line 127) -* AM_EXEEXT: Write configure.in. (line 86) -* AM_INIT_AUTOMAKE: Write configure.in. (line 48) -* AM_MAINTAINER_MODE: Write configure.in. (line 70) -* AM_PROG_LIBTOOL: Write configure.in. (line 122) -* AM_PROG_LIBTOOL in configure: FAQ. (line 19) -* build option: Build and Host Options. - (line 9) -* building with a cross compiler: Canadian Cross. (line 6) -* canadian cross: Canadian Cross. (line 6) -* canadian cross in configure: CCross in Configure. (line 6) -* canadian cross in cygnus tree: CCross in Cygnus Tree. - (line 6) -* canadian cross in makefile: CCross in Make. (line 6) -* canadian cross, configuring: Build and Host Options. - (line 6) -* canonical system names: Configuration Names. (line 6) -* config.cache: Build Files Description. - (line 28) -* config.h: Build Files Description. - (line 23) -* config.h.in: Generated Developer Files. - (line 45) -* config.in: Generated Developer Files. - (line 45) -* config.status: Build Files Description. - (line 9) -* config.status --recheck: FAQ. (line 40) -* configuration names: Configuration Names. (line 6) -* configuration triplets: Configuration Names. (line 6) -* configure: Generated Developer Files. - (line 21) -* configure build system: Build and Host Options. - (line 9) -* configure host: Build and Host Options. - (line 14) -* configure target: Specifying the Target. - (line 10) -* configure.in: Written Developer Files. - (line 9) -* configure.in, writing: Write configure.in. (line 6) -* configuring a canadian cross: Build and Host Options. - (line 6) -* cross compiler: Cross Compilation Concepts. - (line 6) -* cross compiler, building with: Canadian Cross. (line 6) -* cross tools: Cross Compilation Tools. - (line 6) -* CY_GNU_GETTEXT in configure: FAQ. (line 19) -* cygnus configure: Cygnus Configure. (line 6) -* goals: Goals. (line 6) -* history: History. (line 6) -* host names: Configuration Names. (line 6) -* host option: Build and Host Options. - (line 14) -* host system: Host and Target. (line 6) -* host triplets: Configuration Names. (line 6) -* HOST_CC: CCross in Make. (line 27) -* libg++ configure: Cygnus Configure in C++ Libraries. - (line 6) -* libio configure: Cygnus Configure in C++ Libraries. - (line 6) -* libstdc++ configure: Cygnus Configure in C++ Libraries. - (line 6) -* Makefile: Build Files Description. - (line 18) -* Makefile, garbage characters: FAQ. (line 29) -* Makefile.am: Written Developer Files. - (line 18) -* Makefile.am, writing: Write Makefile.am. (line 6) -* Makefile.in: Generated Developer Files. - (line 26) -* multilibs: Multilibs. (line 6) -* stamp-h: Build Files Description. - (line 41) -* stamp-h.in: Generated Developer Files. - (line 54) -* system names: Configuration Names. (line 6) -* system types: Configuration Names. (line 6) -* target option: Specifying the Target. - (line 10) -* target system: Host and Target. (line 6) -* triplets: Configuration Names. (line 6) -* undefined macros: FAQ. (line 12) - - - -Tag Table: -Node: Top978 -Node: Introduction1506 -Node: Goals2588 -Node: Tools3312 -Node: History4306 -Node: Building7304 -Node: Getting Started10399 -Node: Write configure.in10912 -Node: Write Makefile.am18163 -Node: Write acconfig.h21340 -Node: Generate files22877 -Node: Getting Started Example24843 -Node: Getting Started Example 125598 -Node: Getting Started Example 227519 -Node: Getting Started Example 330514 -Node: Generate Files in Example32878 -Node: Files33968 -Node: Developer Files34579 -Node: Developer Files Picture34959 -Node: Written Developer Files36247 -Node: Generated Developer Files38799 -Node: Build Files41943 -Node: Build Files Picture42604 -Node: Build Files Description43368 -Node: Support Files45374 -Node: Configuration Names48256 -Node: Configuration Name Definition48756 -Node: Using Configuration Names51079 -Node: Cross Compilation Tools53049 -Node: Cross Compilation Concepts53740 -Node: Host and Target54708 -Node: Using the Host Type56209 -Node: Specifying the Target57558 -Node: Using the Target Type58347 -Node: Cross Tools in the Cygnus Tree61778 -Node: Host and Target Libraries62835 -Node: Target Library Configure Scripts66584 -Node: Make Targets in Cygnus Tree69676 -Node: Target libiberty71024 -Node: Canadian Cross72411 -Node: Canadian Cross Example73252 -Node: Canadian Cross Concepts74371 -Node: Build Cross Host Tools75883 -Node: Build and Host Options76835 -Node: CCross not in Cygnus Tree78621 -Node: CCross in Cygnus Tree79599 -Node: Standard Cygnus CCross80020 -Node: Cross Cygnus CCross81384 -Node: Supporting Canadian Cross84184 -Node: CCross in Configure84799 -Node: CCross in Make87967 -Node: Cygnus Configure89570 -Node: Cygnus Configure Basics90405 -Node: Cygnus Configure in C++ Libraries95083 -Node: Multilibs96090 -Node: Multilibs in gcc97135 -Node: Multilibs in Target Libraries98213 -Node: FAQ102404 -Node: Index106504 - -End Tag Table diff --git a/etc/standards.info b/etc/standards.info deleted file mode 100644 index 50ee69bdd..000000000 --- a/etc/standards.info +++ /dev/null @@ -1,4930 +0,0 @@ -This is standards.info, produced by makeinfo version 4.7 from -.././etc/standards.texi. - -START-INFO-DIR-ENTRY -* Standards: (standards). GNU coding standards. -END-INFO-DIR-ENTRY - - GNU Coding Standards Copyright (C) 1992, 1993, 1994, 1995, 1996, -1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. - - Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.1 or -any later version published by the Free Software Foundation; with no -Invariant Sections, with no Front-Cover Texts, and with no Back-Cover -Texts. A copy of the license is included in the section entitled "GNU -Free Documentation License". - - -File: standards.info, Node: Top, Next: Preface, Prev: (dir), Up: (dir) - -Version -******* - -Last updated February 14, 2002. - -* Menu: - -* Preface:: About the GNU Coding Standards -* Legal Issues:: Keeping Free Software Free -* Design Advice:: General Program Design -* Program Behavior:: Program Behavior for All Programs -* Writing C:: Making The Best Use of C -* Documentation:: Documenting Programs -* Managing Releases:: The Release Process -* References:: References to Non-Free Software or Documentation -* Copying This Manual:: How to Make Copies of This Manual -* Index:: - - -File: standards.info, Node: Preface, Next: Legal Issues, Prev: Top, Up: Top - -1 About the GNU Coding Standards -******************************** - -The GNU Coding Standards were written by Richard Stallman and other GNU -Project volunteers. Their purpose is to make the GNU system clean, -consistent, and easy to install. This document can also be read as a -guide to writing portable, robust and reliable programs. It focuses on -programs written in C, but many of the rules and principles are useful -even if you write in another programming language. The rules often -state reasons for writing in a certain way. - - This release of the GNU Coding Standards was last updated February -14, 2002. - - If you did not obtain this file directly from the GNU project and -recently, please check for a newer version. You can ftp the GNU Coding -Standards from any GNU FTP host in the directory `/pub/gnu/standards/'. -The GNU Coding Standards are available there in several different -formats: `standards.text', `standards.info', and `standards.dvi', as -well as the Texinfo "source" which is divided in two files: -`standards.texi' and `make-stds.texi'. The GNU Coding Standards are -also available on the GNU World Wide Web server: -`http://www.gnu.org/prep/standards_toc.html'. - - Corrections or suggestions for this document should be sent to -<bug-standards@gnu.org>. If you make a suggestion, please include a -suggested new wording for it; our time is limited. We prefer a context -diff to the `standards.texi' or `make-stds.texi' files, but if you -don't have those files, please mail your suggestion anyway. - - These standards cover the minimum of what is important when writing a -GNU package. Likely, the needs for additional standards will come up. -Sometimes, you might suggest that such standards be added to this -document. If you think your standards would be generally useful, please -do suggest them. - - You should also set standards for your package on many questions not -addressed or not firmly specified here. The most important point is to -be self-consistent--try to stick to the conventions you pick, and try -to document them as much as possible. That way, your program will be -more maintainable by others. - - -File: standards.info, Node: Legal Issues, Next: Design Advice, Prev: Preface, Up: Top - -2 Keeping Free Software Free -**************************** - -This node discusses how you can make sure that GNU software avoids -legal difficulties, and other related issues. - -* Menu: - -* Reading Non-Free Code:: Referring to Proprietary Programs -* Contributions:: Accepting Contributions -* Trademarks:: How We Deal with Trademark Issues - - -File: standards.info, Node: Reading Non-Free Code, Next: Contributions, Up: Legal Issues - -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.) - - If you have a vague recollection of the internals of a Unix program, -this does not absolutely mean you can't write an imitation of it, but -do try to organize the imitation internally along different lines, -because this is likely to make the details of the Unix version -irrelevant and dissimilar to your results. - - For example, Unix utilities were generally optimized to minimize -memory use; if you go for speed instead, your program will be very -different. You could keep the entire input file in core and scan it -there instead of using stdio. Use a smarter algorithm discovered more -recently than the Unix program. Eliminate use of temporary files. Do -it in one pass instead of two (we did this in the assembler). - - Or, on the contrary, emphasize simplicity instead of speed. For some -applications, the speed of today's computers makes simpler algorithms -adequate. - - Or go for generality. For example, Unix programs often have static -tables or fixed-size strings, which make for arbitrary limits; use -dynamic allocation instead. Make sure your program handles NULs and -other funny characters in the input files. Add a programming language -for extensibility and write part of the program in that language. - - Or turn some parts of the program into independently usable -libraries. Or use a simple garbage collector instead of tracking -precisely when to free memory, or use a new GNU facility such as -obstacks. - - -File: standards.info, Node: Contributions, Next: Trademarks, Prev: Reading Non-Free Code, Up: Legal Issues - -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. - - So, before adding in any contributions from other people, please tell -us, so we can arrange to get the papers. Then wait until we tell you -that we have received the signed papers, before you actually use the -contribution. - - This applies both before you release the program and afterward. If -you receive diffs to fix a bug, and they make significant changes, we -need legal papers for that change. - - This also applies to comments and documentation files. For copyright -law, comments and code are just text. Copyright applies to all kinds of -text, so we need legal papers for all kinds. - - We know it is frustrating to ask for legal papers; it's frustrating -for us as well. But if you don't wait, you are going out on a limb--for -example, what if the contributor's employer won't sign a disclaimer? -You might have to take that code out again! - - You don't need papers for changes of a few lines here or there, since -they are not significant for copyright purposes. Also, you don't need -papers if all you get from the suggestion is some ideas, not actual code -which you use. For example, if someone send you one implementation, but -you write a different implementation of the same idea, you don't need to -get papers. - - The very worst thing is if you forget to tell us about the other -contributor. We could be very embarrassed in court some day as a -result. - - We have more detailed advice for maintainers of programs; if you have -reached the stage of actually maintaining a program for GNU (whether -released or not), please ask us for a copy. - - -File: standards.info, Node: Trademarks, Prev: Contributions, Up: Legal Issues - -2.3 Trademarks -============== - -Please do not include any trademark acknowledgements in GNU software -packages or documentation. - - Trademark acknowledgements are the statements that such-and-such is a -trademark of so-and-so. The GNU Project has no objection to the basic -idea of trademarks, but these acknowledgements feel like kowtowing, so -we don't use them. There is no legal requirement for them. - - What is legally required, as regards other people's trademarks, is to -avoid using them in ways which a reader might read as naming or labeling -our own programs or activities. For example, since "Objective C" is -(or at least was) a trademark, we made sure to say that we provide a -"compiler for the Objective C language" rather than an "Objective C -compiler". The latter is meant to be short for the former, but it does -not explicitly state the relationship, so it could be misinterpreted as -using "Objective C" as a label for the compiler rather than for the -language. - - -File: standards.info, Node: Design Advice, Next: Program Behavior, Prev: Legal Issues, Up: Top - -3 General Program Design -************************ - -This node discusses some of the issues you should take into account -when designing your program. - -* Menu: - -* Source Language:: Which languges to use. -* Compatibility:: Compatibility with other implementations -* Using Extensions:: Using non-standard features -* Standard C:: Using Standard C features -* Conditional Compilation:: Compiling Code Only If A Conditional is True - - -File: standards.info, Node: Source Language, Next: Compatibility, Up: Design Advice - -3.1 Which Languages to Use -========================== - -When you want to use a language that gets compiled and runs at high -speed, the best language to use is C. Using another language is like -using a non-standard feature: it will cause trouble for users. Even if -GCC supports the other language, users may find it inconvenient to have -to install the compiler for that other language in order to build your -program. For example, if you write your program in C++, people will -have to install the GNU C++ compiler in order to compile your program. - - C has one other advantage over C++ and other compiled languages: more -people know C, so more people will find it easy to read and modify the -program if it is written in C. - - So in general it is much better to use C, rather than the comparable -alternatives. - - But there are two exceptions to that conclusion: - - * It is no problem to use another language to write a tool - specifically intended for use with that language. That is because - the only people who want to build the tool will be those who have - installed the other language anyway. - - * If an application is of interest only to a narrow part of the - community, then the question of which language it is written in - has less effect on other people, so you may as well please - yourself. - - Many programs are designed to be extensible: they include an -interpreter for a language that is higher level than C. Often much of -the program is written in that language, too. The Emacs editor -pioneered this technique. - - The standard extensibility interpreter for GNU software is GUILE, -which implements the language Scheme (an especially clean and simple -dialect of Lisp). `http://www.gnu.org/software/guile/'. We don't -reject programs written in other "scripting languages" such as Perl and -Python, but using GUILE is very important for the overall consistency of -the GNU system. - - -File: standards.info, Node: Compatibility, Next: Using Extensions, Prev: Source Language, Up: Design Advice - -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. - - When these standards conflict, it is useful to offer compatibility -modes for each of them. - - Standard C and POSIX prohibit many kinds of extensions. Feel free -to make the extensions anyway, and include a `--ansi', `--posix', or -`--compatible' option to turn them off. However, if the extension has -a significant chance of breaking any real programs or scripts, then it -is not really upward compatible. So you should try to redesign its -interface to make it upward compatible. - - Many GNU programs suppress extensions that conflict with POSIX if the -environment variable `POSIXLY_CORRECT' is defined (even if it is -defined with a null value). Please make your program recognize this -variable if appropriate. - - When a feature is used only by users (not by programs or command -files), and it is done poorly in Unix, feel free to replace it -completely with something totally different and better. (For example, -`vi' is replaced with Emacs.) But it is nice to offer a compatible -feature as well. (There is a free `vi' clone, so we offer it.) - - Additional useful features are welcome regardless of whether there -is any precedent for them. - - -File: standards.info, Node: Using Extensions, Next: Standard C, Prev: Compatibility, Up: Design Advice - -3.3 Using Non-standard Features -=============================== - -Many GNU facilities that already exist support a number of convenient -extensions over the comparable Unix facilities. Whether to use these -extensions in implementing your program is a difficult question. - - On the one hand, using the extensions can make a cleaner program. -On the other hand, people will not be able to build the program unless -the other GNU tools are available. This might cause the program to -work on fewer kinds of machines. - - With some extensions, it might be easy to provide both alternatives. -For example, you can define functions with a "keyword" `INLINE' and -define that as a macro to expand into either `inline' or nothing, -depending on the compiler. - - In general, perhaps it is best not to use the extensions if you can -straightforwardly do without them, but to use the extensions if they -are a big improvement. - - An exception to this rule are the large, established programs (such -as Emacs) which run on a great variety of systems. Using GNU -extensions in such programs would make many users unhappy, so we don't -do that. - - Another exception is for programs that are used as part of -compilation: anything that must be compiled with other compilers in -order to bootstrap the GNU compilation facilities. If these require -the GNU compiler, then no one can compile them without having them -installed already. That would be extremely troublesome in certain -cases. - - -File: standards.info, Node: Standard C, Next: Conditional Compilation, Prev: Using Extensions, Up: Design Advice - -3.4 Standard C and Pre-Standard C -================================= - -1989 Standard C is widespread enough now that it is ok to use its -features in new programs. There is one exception: do not ever use the -"trigraph" feature of Standard C. - - 1999 Standard C is not widespread yet, so please do not require its -features in programs. It is ok to use its features if they are present. - - 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 - - -File: standards.info, Node: Conditional Compilation, Prev: Standard C, Up: Design Advice - -3.5 Conditional Compilation -=========================== - -When supporting configuration options already known when building your -program we prefer using `if (... )' over conditional compilation, as in -the former case the compiler is able to perform more extensive checking -of all possible code paths. - - 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. - - While this is not a silver bullet solving all portability problems, -following this policy would have saved the GCC project alone many person -hours if not 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 - - -File: standards.info, Node: Program Behavior, Next: Writing C, Prev: Design Advice, Up: Top - -4 Program Behavior for All Programs -*********************************** - -This node describes conventions for writing robust software. It also -describes general standards for error messages, the command line -interface, and how libraries should behave. - -* Menu: - -* Semantics:: Writing robust programs -* Libraries:: Library behavior -* Errors:: Formatting error messages -* User Interfaces:: Standards about interfaces generally -* Graphical Interfaces:: Standards for graphical interfaces -* Command-Line Interfaces:: Standards for command line interfaces -* Option Table:: Table of long options -* Memory Usage:: When and how to care about memory needs -* File Usage:: Which files to use, and where - - -File: standards.info, Node: Semantics, Next: Libraries, Up: Program Behavior - -4.1 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' 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 libiberty. - - In bash, use `set -C' to avoid this problem. - - -File: standards.info, Node: Libraries, Next: Errors, Prev: Semantics, Up: Program Behavior - -4.2 Library Behavior -==================== - -Try to make library functions reentrant. If they need to do dynamic -storage allocation, at least try to avoid any nonreentrancy aside from -that of `malloc' itself. - - Here are certain name conventions for libraries, to avoid name -conflicts. - - Choose a name prefix for the library, more than two characters long. -All external function and variable names should start with this prefix. -In addition, there should only be one of these in any given library -member. This usually means putting each one in a separate source file. - - An exception can be made when two external symbols are always used -together, so that no reasonable program could use one without the -other; then they can both go in the same file. - - External symbols that are not documented entry points for the user -should have names beginning with `_'. The `_' should be followed by -the chosen name prefix for the library, to prevent collisions with -other libraries. These can go in the same files with user entry points -if you like. - - Static functions and variables can be used as you like and need not -fit any naming convention. - - -File: standards.info, Node: Errors, Next: User Interfaces, Prev: Libraries, Up: Program Behavior - -4.3 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 this format: - - 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. - - 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 - - In an interactive program (one that is reading commands from a -terminal), it is better not to include the program name in an error -message. The place to indicate which program is running is in the -prompt or with the screen layout. (When the same program runs with -input from a source other than a terminal, it is not interactive and -would do best to print error messages using the noninteractive style.) - - The string MESSAGE should not begin with a capital letter when it -follows a program name and/or file name. Also, it should not end with -a period. - - Error messages from interactive programs, and other messages such as -usage messages, should start with a capital letter. But they should not -end with a period. - - -File: standards.info, Node: User Interfaces, Next: Graphical Interfaces, Prev: Errors, Up: Program Behavior - -4.4 Standards for Interfaces Generally -====================================== - -Please don't make the behavior of a utility depend on the name used to -invoke it. It is useful sometimes to make a link to a utility with a -different name, and that should not change what it does. - - Instead, use a run time option or a compilation switch or both to -select among the alternate behaviors. - - Likewise, please don't make the behavior of the program depend on the -type of output device it is used with. Device independence is an -important principle of the system's design; do not compromise it merely -to save someone from typing an option now and then. (Variation in error -message syntax when using a terminal is ok, because that is a side issue -that people do not depend on.) - - If you think one behavior is most useful when the output is to a -terminal, and another is most useful when the output is a file or a -pipe, then it is usually best to make the default behavior the one that -is useful with output to a terminal, and have an option for the other -behavior. - - Compatibility requires certain programs to depend on the type of -output device. It would be disastrous if `ls' or `sh' did not do so in -the way all users expect. In some of these cases, we supplement the -program with a preferred alternate version that does not depend on the -output device type. For example, we provide a `dir' program much like -`ls' except that its default output format is always multi-column -format. - - -File: standards.info, Node: Graphical Interfaces, Next: Command-Line Interfaces, Prev: User Interfaces, Up: Program Behavior - -4.5 Standards for Graphical Interfaces -====================================== - -When you write a program that provides a graphical user interface, -please make it work with X Windows and the GTK toolkit unless the -functionality specifically requires some alternative (for example, -"displaying jpeg images while in console mode"). - - In addition, please provide a command-line interface to control the -functionality. (In many cases, the graphical user interface can be a -separate program which invokes the command-line program.) This is so -that the same jobs can be done from scripts. - - Please also consider providing a CORBA interface (for use from -GNOME), a library interface (for use from C), and perhaps a -keyboard-driven console interface (for use by users from console mode). -Once you are doing the work to provide the functionality and the -graphical interface, these won't be much extra work. - - -File: standards.info, Node: Command-Line Interfaces, Next: Option Table, Prev: Graphical Interfaces, Up: Program Behavior - -4.6 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 (*note Option Table::). - - It is usually a good idea for file names given as ordinary arguments -to be input files only; any output files would be specified using -options (preferably `-o' or `--output'). Even if you allow an output -file name as an ordinary argument for compatibility, try to provide an -option as another way to specify it. This will lead to more consistency -among GNU utilities, and fewer idiosyncracies for users to remember. - - All programs should support two standard options: `--version' and -`--help'. - -`--version' - This option should direct the program to print information about - its name, version, origin and legal status, all on standard - output, and then exit successfully. Other options and arguments - should be ignored once this is seen, and the program should not - perform its normal function. - - The first line is meant to be easy for a program to parse; the - version number proper starts after the last space. In addition, - it contains the canonical name for this program, in this format: - - GNU Emacs 19.30 - - The program's name should be a constant string; _don't_ compute it - from `argv[0]'. The idea is to state the standard or canonical - name for the program, not its file name. There are other ways to - find out the precise file name where a command is found in `PATH'. - - If the program is a subsidiary part of a larger package, mention - the package name in parentheses, like this: - - emacsserver (GNU Emacs) 19.30 - - If the package has a version number which is different from this - program's version number, you can mention the package version - number just before the close-parenthesis. - - If you *need* to mention the version numbers of libraries which - are distributed separately from the package which contains this - program, you can do so by printing an additional line of version - info for each library you want to mention. Use the same format - for these lines as for the first line. - - Please do not mention all of the libraries that the program uses - "just for completeness"--that would produce a lot of unhelpful - clutter. Please mention library version numbers only if you find - in practice that they are very important to you in debugging. - - The following line, after the version number line or lines, should - be a copyright notice. If more than one copyright notice is - called for, put each on a separate line. - - Next should follow a brief statement that the program is free - software, and that users are free to copy and change it on certain - conditions. If the program is covered by the GNU GPL, say so - here. Also mention that there is no warranty, to the extent - permitted by law. - - It is ok to finish the output with a list of the major authors of - the program, as a way of giving credit. - - Here's an example of output that follows these rules: - - GNU Emacs 19.34.5 - Copyright (C) 1996 Free Software Foundation, Inc. - GNU Emacs comes with NO WARRANTY, - to the extent permitted by law. - You may redistribute copies of GNU Emacs - under the terms of the GNU General Public License. - For more information about these matters, - see the files named COPYING. - - 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. - - This copyright notice only needs to mention the most recent year in - which changes were made--there's no need to list the years for - previous versions' changes. You don't have to mention the name of - the program in these notices, if that is inconvenient, since it - appeared in the first line. - - Translations of the above lines must preserve the validity of the - copyright notices (*note Internationalization::). If the - translation's character set supports it, the `(C)' should be - replaced with the copyright symbol, as follows: - - (the official copyright symbol, which is the letter C in a circle); - - Write the word "Copyright" exactly like that, in English. Do not - translate it into another language. International treaties - recognize the English word "Copyright"; translations into other - languages do not have legal significance. - -`--help' - This 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 there should be a line - that says where to mail bug reports. It should have this format: - - Report bugs to MAILING-ADDRESS. - - -File: standards.info, Node: Option Table, Next: Memory Usage, Prev: Command-Line Interfaces, Up: Program Behavior - -4.7 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 `info', `gawk', Make, `mt', and `tar'; `-n' in `sed'; `-r' - in `touch'. - -`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' - No listing of which programs already use this; someone should - check to see if any actually do, and tell <gnu@gnu.org>. - -`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-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. *Note:* 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-limit' - Used in `makeinfo'. - -`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. *Note:* 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 nonpriveledged 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'. - - -File: standards.info, Node: Memory Usage, Next: File Usage, Prev: Option Table, Up: Program Behavior - -4.8 Memory Usage -================ - -If a program typically uses just a few meg of memory, don't bother -making any effort to reduce memory usage. For example, if it is -impractical for other reasons to operate on files more than a few meg -long, it is reasonable to read entire input files into core to operate -on them. - - However, for programs such as `cat' or `tail', that can usefully -operate on very large files, it is important to avoid using a technique -that would artificially limit the size of files it can handle. If a -program works by lines and could be applied to arbitrary user-supplied -input files, it should keep only a line in memory, because this is not -very hard and users will want to be able to operate on input files that -are bigger than will fit in core all at once. - - If your program creates complicated data structures, just make them -in core and give a fatal error if `malloc' returns zero. - - -File: standards.info, Node: File Usage, Prev: Memory Usage, Up: Program Behavior - -4.9 File Usage -============== - -Programs should be prepared to operate when `/usr' and `/etc' are -read-only file systems. Thus, if the program manages log files, lock -files, backup files, score files, or any other files which are modified -for internal purposes, these files should not be stored in `/usr' or -`/etc'. - - There are two exceptions. `/etc' is used to store system -configuration information; it is reasonable for a program to modify -files in `/etc' when its job is to update the system configuration. -Also, if the user explicitly asks to modify one file in a directory, it -is reasonable for the program to store other files in the same -directory. - - -File: standards.info, Node: Writing C, Next: Documentation, Prev: Program Behavior, Up: Top - -5 Making The Best Use of C -************************** - -This node provides advice on how best to use the C language when -writing GNU software. - -* Menu: - -* Formatting:: Formatting Your Source Code -* Comments:: Commenting Your Work -* Syntactic Conventions:: Clean Use of C Constructs -* Names:: Naming Variables, Functions, and Files -* System Portability:: Portability between different operating systems -* CPU Portability:: Supporting the range of CPU types -* System Functions:: Portability and ``standard'' library functions -* Internationalization:: Techniques for internationalization -* Mmap:: How you can safely use `mmap'. - - -File: standards.info, Node: Formatting, Next: Comments, Up: Writing C - -5.1 Formatting Your Source Code -=============================== - -It is important to put the open-brace that starts the body of a C -function in column zero, and avoid putting any other open-brace or -open-parenthesis or open-bracket in column zero. Several tools look -for open-braces in column zero to find the beginnings of C functions. -These tools will not work on code not formatted that way. - - It is also important for function definitions to start the name of -the function in column zero. This helps people to search for function -definitions, and may also help certain tools recognize them. Thus, the -proper format is this: - - static char * - concat (s1, s2) /* Name starts in column zero here */ - char *s1, *s2; - { /* Open brace in column zero here */ - ... - } - -or, if you want to use Standard C syntax, format the definition like -this: - - static char * - concat (char *s1, char *s2) - { - ... - } - - In Standard C, if the arguments don't fit nicely on one line, split -it like this: - - int - lots_of_args (int an_integer, long a_long, short a_short, - double a_double, float a_float) - ... - - 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 - - We don't think of these recommendations as requirements, because it -causes no problems for users if two different programs have different -formatting styles. - - But whatever style you use, please use it consistently, since a -mixture of styles within one program tends to look ugly. If you are -contributing changes to an existing program, please follow the style of -that program. - - For the body of the function, our recommended style looks like this: - - if (x < foo (y, z)) - haha = bar[4] + 5; - else - { - while (z) - { - haha += foo (z, z); - z--; - } - return ++x + bar (); - } - - We find it easier to read a program when it has spaces before the -open-parentheses and after the commas. Especially after the commas. - - When you split an expression into multiple lines, split it before an -operator, not after one. Here is the right way: - - if (foo_this_is_long && bar > win (x, y, z) - && remaining_condition) - - Try to avoid having two operators of different precedence at the same -level of indentation. For example, don't write this: - - mode = (inmode[j] == VOIDmode - || GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j]) - ? outmode[j] : inmode[j]); - - Instead, use extra parentheses so that the indentation shows the -nesting: - - mode = ((inmode[j] == VOIDmode - || (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j]))) - ? outmode[j] : inmode[j]); - - 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. - - -File: standards.info, Node: Comments, Next: Syntactic Conventions, Prev: Formatting, Up: Writing C - -5.2 Commenting Your Work -======================== - -Every program should start with a comment saying briefly what it is for. -Example: `fmt - filter for simple filling of text'. - - Please write the comments in a GNU program in English, because -English is the one language that nearly all programmers in all -countries can read. If you do not write English well, please write -comments in English as well as you can, then ask other people to help -rewrite them. If you can't write comments in English, please find -someone to work with you and translate your comments into English. - - Please put a comment on each function saying what the function does, -what sorts of arguments it gets, and what the possible values of -arguments mean and are used for. It is not necessary to duplicate in -words the meaning of the C argument declarations, if a C type is being -used in its customary fashion. If there is anything nonstandard about -its use (such as an argument of type `char *' which is really the -address of the second character of a string, not the first), or any -possible values that would not work the way one would expect (such as, -that strings containing newlines are not guaranteed to work), be sure -to say so. - - Also explain the significance of the return value, if there is one. - - Please put two spaces after the end of a sentence in your comments, -so that the Emacs sentence commands will work. Also, please write -complete sentences and capitalize the first word. If a lower-case -identifier comes at the beginning of a sentence, don't capitalize it! -Changing the spelling makes it a different identifier. If you don't -like starting a sentence with a lower case letter, write the sentence -differently (e.g., "The identifier lower-case is ..."). - - The comment on a function is much clearer if you use the argument -names to speak about the argument values. The variable name itself -should be lower case, but write it in upper case when you are speaking -about the value rather than the variable itself. Thus, "the inode -number NODE_NUM" rather than "an inode". - - There is usually no purpose in restating the name of the function in -the comment before it, because the reader can see that for himself. -There might be an exception when the comment is so long that the -function itself would be off the bottom of the screen. - - There should be a comment on each static variable as well, like this: - - /* Nonzero means truncate lines in the display; - zero means continue them. */ - int truncate_lines; - - 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 */ - - -File: standards.info, Node: Syntactic Conventions, Next: Names, Prev: Comments, Up: Writing C - -5.3 Clean Use of C Constructs -============================= - -Please explicitly declare the types of all objects. For example, you -should explicitly declare all arguments to functions, and you should -declare functions to return `int' rather than omitting the `int'. - - Some programmers like to use the GCC `-Wall' option, and change the -code whenever it issues a warning. If you want to do this, then do. -Other programmers prefer not to use `-Wall', because it gives warnings -for valid and legitimate code which they do not want to change. If you -want to do this, then do. The compiler should be your servant, not -your master. - - Declarations of external functions and functions to appear later in -the source file should all go in one place near the beginning of the -file (somewhere before the first function definition in the file), or -else should go in a header file. Don't put `extern' declarations inside -functions. - - 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 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. - - Don't declare multiple variables in one declaration that spans lines. -Start a new declaration on each line, instead. For example, instead of -this: - - int foo, - bar; - -write either this: - - int foo, bar; - -or this: - - int foo; - int bar; - -(If they are global variables, each should have a comment preceding it -anyway.) - - When you have an `if'-`else' statement nested in another `if' -statement, always put braces around the `if'-`else'. Thus, never write -like this: - - if (foo) - if (bar) - win (); - else - lose (); - -always like this: - - if (foo) - { - if (bar) - win (); - else - lose (); - } - - If you have an `if' statement nested inside of an `else' statement, -either write `else if' on one line, like this, - - if (foo) - ... - else if (bar) - ... - -with its `then'-part indented like the preceding `then'-part, or write -the nested `if' within braces like this: - - if (foo) - ... - else - { - if (bar) - ... - } - - Don't declare both a structure tag and variables or typedefs in the -same declaration. Instead, declare the structure tag separately and -then use it to declare the variables or typedefs. - - Try to avoid assignments inside `if'-conditions. For example, don't -write this: - - if ((foo = (char *) malloc (sizeof *foo)) == 0) - fatal ("virtual memory exhausted"); - -instead, write this: - - foo = (char *) malloc (sizeof *foo); - if (foo == 0) - fatal ("virtual memory exhausted"); - - Don't make the program ugly to placate `lint'. Please don't insert -any casts to `void'. Zero without a cast is perfectly fine as a null -pointer constant, except when calling a varargs function. - - -File: standards.info, Node: Names, Next: System Portability, Prev: Syntactic Conventions, Up: Writing C - -5.4 Naming Variables, Functions, and Files -========================================== - -The names of global variables and functions in a program serve as -comments of a sort. So don't choose terse names--instead, look for -names that give useful information about the meaning of the variable or -function. In a GNU program, names should be English, like other -comments. - - Local variable names can be shorter, because they are used only -within one context, where (presumably) comments explain their purpose. - - Try to limit your use of abbreviations in symbol names. It is ok to -make a few abbreviations, explain what they mean, and then use them -frequently, but don't use lots of obscure abbreviations. - - Please use underscores to separate words in a name, so that the Emacs -word commands can be useful within them. Stick to lower case; reserve -upper case for macros and `enum' constants, and for name-prefixes that -follow a uniform convention. - - For example, you should use names like `ignore_space_change_flag'; -don't use names like `iCantReadThis'. - - Variables that indicate whether command-line options have been -specified should be named after the meaning of the option, not after -the option-letter. A comment should state both the exact meaning of -the option and its letter. For example, - - /* Ignore changes in horizontal whitespace (-b). */ - int ignore_space_change_flag; - - When you want to define names with constant integer values, use -`enum' rather than `#define'. GDB knows about enumeration constants. - - You might want to make sure that none of the file names would -conflict the files were loaded onto an MS-DOS file system which -shortens the names. You can use the program `doschk' to test for this. - - Some GNU programs were designed to limit themselves to file names of -14 characters or less, to avoid file name conflicts if they are read -into older System V systems. Please preserve this feature in the -existing GNU programs that have it, but there is no need to do this in -new GNU programs. `doschk' also reports file names longer than 14 -characters. - - -File: standards.info, Node: System Portability, Next: CPU Portability, Prev: Names, Up: Writing C - -5.5 Portability between System Types -==================================== - -In the Unix world, "portability" refers to porting to different Unix -versions. For a GNU program, this kind of portability is desirable, but -not paramount. - - The primary purpose of GNU software is to run on top of the GNU -kernel, compiled with the GNU C compiler, on various types of CPU. So -the kinds of portability that are absolutely necessary are quite -limited. But it is important to support Linux-based GNU systems, since -they are the form of GNU that is popular. - - Beyond that, it is good to support the other free operating systems -(*BSD), and it is nice to support other Unix-like systems if you want -to. Supporting a variety of Unix-like systems is desirable, although -not paramount. It is usually not too hard, so you may as well do it. -But you don't have to consider it an obligation, if it does turn out to -be hard. - - 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. - - Avoid using the format of semi-internal data bases (e.g., -directories) when there is a higher-level alternative (`readdir'). - - As for systems that are not like Unix, such as MSDOS, Windows, the -Macintosh, VMS, and MVS, supporting them is often a lot of work. When -that is the case, it is better to spend your time adding features that -will be useful on GNU and GNU/Linux, rather than on supporting other -incompatible systems. - - It is a good idea to define the "feature test macro" `_GNU_SOURCE' -when compiling your C files. When you compile on GNU or GNU/Linux, -this will enable the declarations of GNU library extension functions, -and that will usually give you a compiler error message if you define -the same function names in some other way in your program. (You don't -have to actually _use_ these functions, if you prefer to make the -program more portable to other systems.) - - But whether or not you use these GNU extensions, you should avoid -using their names for any other meanings. Doing so would make it hard -to move your code into other GNU programs. - - -File: standards.info, Node: CPU Portability, Next: System Functions, Prev: System Portability, Up: Writing C - -5.6 Portability between CPUs -============================ - -Even GNU systems will differ because of differences among CPU -types--for example, difference in byte ordering and alignment -requirements. It is absolutely essential to handle these differences. -However, don't make any effort to cater to the possibility that an -`int' will be less than 32 bits. We don't support 16-bit machines in -GNU. - - Similarly, don't make any effort to cater to the possibility that -`long' will be smaller than predefined types like `size_t'. For -example, the following code is ok: - - printf ("size = %lu\n", (unsigned long) sizeof array); - printf ("diff = %ld\n", (long) (pointer2 - pointer1)); - - 1989 Standard C requires this to work, and we know of only one -counterexample: 64-bit programs on Microsoft Windows IA-64. We will -leave it to those who want to port GNU programs to that environment to -figure out how to do it. - - 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 an `off_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); - - When calling functions, you need not worry about the difference -between pointers of various types, or between pointers and integers. -On most machines, there's no difference anyway. As for the few -machines where there is a difference, all of them support Standard C -prototypes, so you can use prototypes (perhaps conditionalized to be -active only in Standard C) to make the code work on those systems. - - In certain cases, it is ok to pass integer and pointer arguments -indiscriminately to the same function, and use no prototype on any -system. For example, many GNU programs have error-reporting functions -that pass their arguments along to `printf' and friends: - - error (s, a1, a2, a3) - char *s; - char *a1, *a2, *a3; - { - fprintf (stderr, "error: "); - fprintf (stderr, s, a1, a2, a3); - } - -In practice, this works on all machines, since a pointer is generally -the widest possible kind of argument; it is much simpler than any -"correct" alternative. Be sure _not_ to use a prototype for such -functions. - - If you have decided to use Standard C, then you can instead define -`error' using `stdarg.h', and pass the arguments along to `vfprintf'. - - Avoid casting pointers to integers if you can. Such casts greatly -reduce portability, and in most programs they are easy to avoid. In the -cases where casting pointers to integers is essential--such as, a Lisp -interpreter which stores type information as well as an address in one -word--you'll have to make explicit provisions to handle different word -sizes. You will also need to make provision for systems in which the -normal range of addresses you can get from `malloc' starts far away -from zero. - - -File: standards.info, Node: System Functions, Next: Internationalization, Prev: CPU Portability, Up: Writing C - -5.7 Calling System Functions -============================ - -C implementations differ substantially. Standard C reduces but does -not eliminate the incompatibilities; meanwhile, many GNU packages still -support pre-standard compilers because this is not hard to do. This -chapter gives recommendations for how to use the more-or-less standard C -library functions to avoid unnecessary loss of portability. - - * Don't use the return value of `sprintf'. It returns the number of - characters written on some systems, but not on all systems. - - * Be aware that `vfprintf' is not always available. - - * `main' should be declared to return type `int'. It should - terminate either by calling `exit' or by returning the integer - status code; make sure it cannot ever return an undefined value. - - * Don't declare system functions explicitly. - - Almost any declaration for a system function is wrong on some - system. To minimize conflicts, leave it to the system header - files to declare system functions. If the headers don't declare a - function, let it remain undeclared. - - While it may seem unclean to use a function without declaring it, - in practice this works fine for most system library functions on - the systems where this really happens; thus, the disadvantage is - only theoretical. By contrast, actual declarations have - frequently caused actual conflicts. - - * If you must declare a system function, don't specify the argument - types. Use an old-style declaration, not a Standard C prototype. - The more you specify about the function, the more likely a - conflict. - - * In particular, don't unconditionally declare `malloc' or `realloc'. - - Most GNU programs use those functions just once, in functions - conventionally named `xmalloc' and `xrealloc'. These functions - call `malloc' and `realloc', respectively, and check the results. - - Because `xmalloc' and `xrealloc' are defined in your program, you - can declare them in other files without any risk of type conflict. - - On most systems, `int' is the same length as a pointer; thus, the - calls to `malloc' and `realloc' work fine. For the few - exceptional systems (mostly 64-bit machines), you can use - *conditionalized* declarations of `malloc' and `realloc'--or put - these declarations in configuration files specific to those - systems. - - * The string functions require special treatment. Some Unix systems - have a header file `string.h'; others have `strings.h'. Neither - file name is portable. There are two things you can do: use - Autoconf to figure out which file to include, or don't include - either file. - - * If you don't include either strings file, you can't get - declarations for the string functions from the header file in the - usual way. - - That causes less of a problem than you might think. The newer - standard string functions should be avoided anyway because many - systems still don't support them. The string functions you can - use are these: - - strcpy strncpy strcat strncat - strlen strcmp strncmp - strchr strrchr - - The copy and concatenate functions work fine without a declaration - as long as you don't use their values. Using their values without - a declaration fails on systems where the width of a pointer - differs from the width of `int', and perhaps in other cases. It - is trivial to avoid using their values, so do that. - - The compare functions and `strlen' work fine without a declaration - on most systems, possibly all the ones that GNU software runs on. - You may find it necessary to declare them *conditionally* on a few - systems. - - The search functions must be declared to return `char *'. Luckily, - there is no variation in the data type they return. But there is - variation in their names. Some systems give these functions the - names `index' and `rindex'; other systems use the names `strchr' - and `strrchr'. Some systems support both pairs of names, but - neither pair works on all systems. - - You should pick a single pair of names and use it throughout your - program. (Nowadays, it is better to choose `strchr' and `strrchr' - for new programs, since those are the standard names.) Declare - both of those names as functions returning `char *'. On systems - which don't support those names, define them as macros in terms of - the other pair. For example, here is what to put at the beginning - of your file (or in a header) if you want to use the names - `strchr' and `strrchr' throughout: - - #ifndef HAVE_STRCHR - #define strchr index - #endif - #ifndef HAVE_STRRCHR - #define strrchr rindex - #endif - - char *strchr (); - char *strrchr (); - - Here we assume that `HAVE_STRCHR' and `HAVE_STRRCHR' are macros -defined in systems where the corresponding functions exist. One way to -get them properly defined is to use Autoconf. - - -File: standards.info, Node: Internationalization, Next: Mmap, Prev: System Functions, Up: Writing C - -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. - - Using GNU gettext in a package involves specifying a "text domain -name" for the package. The text domain name is used to separate the -translations for this package from the translations for other packages. -Normally, the text domain name should be the same as the name of the -package--for example, `fileutils' for the GNU file utilities. - - To enable gettext to work well, avoid writing code that makes -assumptions about the structure of words or sentences. When you want -the precise text of a sentence to vary depending on the data, use two or -more alternative string constants each containing a complete sentences, -rather than inserting conditionalized words or phrases into a single -sentence framework. - - Here is an example of what not to do: - - printf ("%d file%s processed", nfiles, - nfiles != 1 ? "s" : ""); - -The problem with that example is that it assumes that plurals are made -by adding `s'. If you apply gettext to the format string, like this, - - printf (gettext ("%d file%s processed"), nfiles, - nfiles != 1 ? "s" : ""); - -the message can use different words, but it will still be forced to use -`s' for the plural. Here is a better way: - - printf ((nfiles != 1 ? "%d files processed" - : "%d file processed"), - nfiles); - -This way, you can apply gettext to each of the two strings -independently: - - printf ((nfiles != 1 ? gettext ("%d files processed") - : gettext ("%d file processed")), - nfiles); - -This can be any method of forming the plural of the word for "file", and -also handles languages that require agreement in the word for -"processed". - - A similar problem appears at the level of sentence structure with -this code: - - printf ("# Implicit rule search has%s been done.\n", - f->tried_implicit ? "" : " not"); - -Adding `gettext' calls to this code cannot give correct results for all -languages, because negation in some languages requires adding words at -more than one place in the sentence. By contrast, adding `gettext' -calls does the job straightfowardly if the code starts out like this: - - printf (f->tried_implicit - ? "# Implicit rule search has been done.\n", - : "# Implicit rule search has not been done.\n"); - - -File: standards.info, Node: Mmap, Prev: Internationalization, Up: Writing C - -5.9 Mmap -======== - -Don't assume that `mmap' either works on all files or fails for all -files. It may work on some files and fail on others. - - The proper way to use `mmap' is to try it on the specific file for -which you want to use it--and if `mmap' doesn't work, fall back on -doing the job in another way using `read' and `write'. - - The reason this precaution is needed is that the GNU kernel (the -HURD) provides a user-extensible file system, in which there can be many -different kinds of "ordinary files." Many of them support `mmap', but -some do not. It is important to make programs handle all these kinds -of files. - - -File: standards.info, Node: Documentation, Next: Managing Releases, Prev: Writing C, Up: Top - -6 Documenting Programs -********************** - -A GNU program should ideally come with full free documentation, adequate -for both reference and tutorial purposes. If the package can be -programmed or extended, the documentation should cover programming or -extending it, as well as just using it. - -* Menu: - -* GNU Manuals:: Writing proper manuals. -* Doc Strings and Manuals:: Compiling doc strings doesn't make a manual. -* Manual Structure Details:: Specific structure conventions. -* License for Manuals:: Writing the distribution terms for a manual. -* Manual Credits:: Giving credit to documentation contributors. -* Printed Manuals:: Mentioning the printed manual. -* NEWS File:: NEWS files supplement manuals. -* Change Logs:: Recording Changes -* Man Pages:: Man pages are secondary. -* Reading other Manuals:: How far you can go in learning - from other manuals. - - -File: standards.info, Node: GNU Manuals, Next: Doc Strings and Manuals, Up: Documentation - -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'). - - Nowadays some other formats such as Docbook and Sgmltexi can be -converted automatically into Texinfo. It is ok to produce the Texinfo -documentation by conversion this way, as long as it gives good results. - - Programmers often find it most natural to structure the documentation -following the structure of the implementation, which they know. But -this structure is not necessarily good for explaining how to use the -program; it may be irrelevant and confusing for a user. - - At every level, from the sentences in a paragraph to the grouping of -topics into separate manuals, the right way to structure documentation -is according to the concepts and questions that a user will have in mind -when reading it. Sometimes this structure of ideas matches the -structure of the implementation of the software being documented--but -often they are different. Often the most important part of learning to -write good documentation is learning to notice when you are structuring -the documentation like the implementation, and think about better -alternatives. - - For example, each program in the GNU system probably ought to be -documented in one manual; but this does not mean each program should -have its own manual. That would be following the structure of the -implementation, rather than the structure that helps the user -understand. - - Instead, each manual should cover a coherent _topic_. For example, -instead of a manual for `diff' and a manual for `diff3', we have one -manual for "comparison of files" which covers both of those programs, -as well as `cmp'. By documenting these programs together, we can make -the whole subject clearer. - - 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. - - In general, a GNU manual should serve both as tutorial and reference. -It should be set up for convenient access to each topic through Info, -and for reading straight through (appendixes aside). A GNU manual -should give a good introduction to a beginner reading through from the -start, and should also provide all the details that hackers want. The -Bison manual is a good example of this--please take a look at it to see -what we mean. - - That is not as hard as it first sounds. Arrange each chapter as a -logical breakdown of its topic, but order the sections, and write their -text, so that reading the chapter straight through makes sense. Do -likewise when structuring the book into chapters, and when structuring a -section into paragraphs. The watchword is, _at each point, address the -most fundamental and important issue raised by the preceding text._ - - If necessary, add extra chapters at the beginning of the manual which -are purely tutorial and cover the basics of the subject. These provide -the framework for a beginner to understand the rest of the manual. The -Bison manual provides a good example of how to do this. - - 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 -*Note Making Index Entries: (texinfo)Index Entries, and see *Note -Defining the Entries of an Index: (texinfo)Indexing Commands. - - Don't use Unix man pages as a model for how to write GNU -documentation; most of them are terse, badly structured, and give -inadequate explanation of the underlying concepts. (There are, of -course, some exceptions.) Also, Unix man pages use a particular format -which is different from what we use in GNU manuals. - - Please include an email address in the manual for where to report -bugs _in 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 punishable by law. - - -File: standards.info, Node: Doc Strings and Manuals, Next: Manual Structure Details, Prev: GNU Manuals, Up: Documentation - -6.2 Doc Strings and Manuals -=========================== - -Some programming systems, such as Emacs, provide a documentation string -for each function, command or variable. You may be tempted to write a -reference manual by compiling the documentation strings and writing a -little additional text to go around them--but you must not do it. That -approach is a fundamental mistake. The text of well-written -documentation strings will be entirely wrong for a manual. - - A documentation string needs to stand alone--when it appears on the -screen, there will be no other text to introduce or explain it. -Meanwhile, it can be rather informal in style. - - The text describing a function or variable in a manual must not stand -alone; it appears in the context of a section or subsection. Other text -at the beginning of the section should explain some of the concepts, and -should often make some general points that apply to several functions or -variables. The previous descriptions of functions and variables in the -section will also have given information about the topic. A description -written to stand alone would repeat some of that information; this -redundance looks bad. Meanwhile, the informality that is acceptable in -a documentation string is totally unacceptable in a manual. - - The only good way to use documentation strings in writing a good -manual is to use them as a source of information for writing good text. - - -File: standards.info, Node: Manual Structure Details, Next: License for Manuals, Prev: Doc Strings and Manuals, Up: Documentation - -6.3 Manual Structure Details -============================ - -The title page of the manual should state the version of the programs or -packages documented in the manual. The Top node of the manual should -also contain this information. If the manual is changing more -frequently than or independent of the program, also state a version -number for the manual in both of these places. - - 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 -in a man page for). Start with an `@example' containing a template for -all the options and arguments that the program uses. - - Alternatively, put a menu item in some menu whose item name fits one -of the above patterns. This identifies the node which that item points -to as the node for this purpose, regardless of the node's actual name. - - The `--usage' feature of the Info reader looks for such a node or -menu item in order to find the relevant text, so it is essential for -every Texinfo file to have one. - - If one manual describes several programs, it should have such a node -for each program described in the manual. - - -File: standards.info, Node: License for Manuals, Next: Manual Credits, Prev: Manual Structure Details, Up: Documentation - -6.4 License for Manuals -======================= - -Please use the GNU Free Documentation License for all GNU manuals that -are more than a few pages long. Likewise for a collection of short -documents--you only need one copy of the GNU FDL for the whole -collection. For a single short document, you can use a very permissive -non-copyleft license, to avoid taking up space with a long license. - - See `http://www.gnu.org/copyleft/fdl-howto.html' for more explanation -of how to employ the GFDL. - - Note that it is not obligatory to include a copy of the GNU GPL or -GNU LGPL in a manual whose license is neither the GPL nor the LGPL. It -can be a good idea to include the program's license in a large manual; -in a short manual, whose size would be increased considerably by -including the program's license, it is probably better not to include -it. - - -File: standards.info, Node: Manual Credits, Next: Printed Manuals, Prev: License for Manuals, Up: Documentation - -6.5 Manual Credits -================== - -Please credit the principal human writers of the manual as the authors, -on the title page of the manual. If a company sponsored the work, thank -the company in a suitable place in the manual, but do not cite the -company as an author. - - -File: standards.info, Node: Printed Manuals, Next: NEWS File, Prev: Manual Credits, Up: Documentation - -6.6 Printed Manuals -=================== - -The FSF publishes some GNU manuals in printed form. To encourage sales -of these manuals, the on-line versions of the manual should mention at -the very start that the printed manual is available and should point at -information for getting it--for instance, with a link to the page -`http://www.gnu.org/order/order.html'. This should not be included in -the printed manual, though, because there it is redundant. - - It is also useful to explain in the on-line forms of the manual how -the user can print out the manual from the sources. - - -File: standards.info, Node: NEWS File, Next: Change Logs, Prev: Printed Manuals, Up: Documentation - -6.7 The NEWS File -================= - -In addition to its manual, the package should have a file named `NEWS' -which contains a list of user-visible changes worth mentioning. In -each new release, add items to the front of the file and identify the -version they pertain to. Don't discard old items; leave them in the -file after the newer items. This way, a user upgrading from any -previous version can see what is new. - - If the `NEWS' file gets very long, move some of the older items into -a file named `ONEWS' and put a note at the end referring the user to -that file. - - -File: standards.info, Node: Change Logs, Next: Man Pages, Prev: NEWS File, Up: Documentation - -6.8 Change Logs -=============== - -Keep a change log to describe all the changes made to program source -files. The purpose of this is so that people investigating bugs in the -future will know about the changes that might have introduced the bug. -Often a new bug can be found by looking at what was recently changed. -More importantly, change logs can help you eliminate conceptual -inconsistencies between different parts of a program, by giving you a -history of how the conflicting concepts arose and who they came from. - -* Menu: - -* Change Log Concepts:: -* Style of Change Logs:: -* Simple Changes:: -* Conditional Changes:: -* Indicating the Part Changed:: - - -File: standards.info, Node: Change Log Concepts, Next: Style of Change Logs, Up: Change Logs - -6.8.1 Change Log Concepts -------------------------- - -You can think of the change log as a conceptual "undo list" which -explains how earlier versions were different from the current version. -People can see the current version; they don't need the change log to -tell them what is in it. What they want from a change log is a clear -explanation of how the earlier version differed. - - The change log file is normally called `ChangeLog' and covers an -entire directory. Each directory can have its own change log, or a -directory can use the change log of its parent directory-it's up to you. - - Another alternative is to record change log information with a -version control system such as RCS or CVS. This can be converted -automatically to a `ChangeLog' file using `rcs2log'; in Emacs, the -command `C-x v a' (`vc-update-change-log') does the job. - - There's no need to describe the full purpose of the changes or how -they work together. If you think that a change calls for explanation, -you're probably right. Please do explain it--but please put the -explanation in comments in the code, where people will see it whenever -they see the code. For example, "New function" is enough for the -change log when you add a function, because there should be a comment -before the function definition to explain what it does. - - However, sometimes it is useful to write one line to describe the -overall purpose of a batch of changes. - - The easiest way to add an entry to `ChangeLog' is with the Emacs -command `M-x add-change-log-entry'. An entry should have an asterisk, -the name of the changed file, and then in parentheses the name of the -changed functions, variables or whatever, followed by a colon. Then -describe the changes you made to that function or variable. - - -File: standards.info, Node: Style of Change Logs, Next: Simple Changes, Prev: Change Log Concepts, Up: Change Logs - -6.8.2 Style of Change Logs --------------------------- - -Here are some simple examples of change log entries, starting with the -header line that says who made the change and when, followed by -descriptions of specific changes. (These examples are drawn from Emacs -and GCC.) - - 1998-08-17 Richard Stallman <rms@gnu.org> - - * register.el (insert-register): Return nil. - (jump-to-register): Likewise. - - * sort.el (sort-subr): Return nil. - - * tex-mode.el (tex-bibtex-file, tex-file, tex-region): - Restart the tex shell if process is gone or stopped. - (tex-shell-running): New function. - - * expr.c (store_one_arg): Round size up for move_block_to_reg. - (expand_call): Round up when emitting USE insns. - * stmt.c (assign_parms): Round size up for move_block_from_reg. - - It's important to name the changed function or variable in full. -Don't abbreviate function or variable names, and don't combine them. -Subsequent maintainers will often search for a function name to find all -the change log entries that pertain to it; if you abbreviate the name, -they won't find it when they search. - - For example, some people are tempted to abbreviate groups of function -names by writing `* register.el ({insert,jump-to}-register)'; this is -not a good idea, since searching for `jump-to-register' or -`insert-register' would not find that entry. - - Separate unrelated change log entries with blank lines. When two -entries represent parts of the same change, so that they work together, -then don't put blank lines between them. Then you can omit the file -name and the asterisk when successive entries are in the same file. - - Break long lists of function names by closing continued lines with -`)', rather than `,', and opening the continuation with `(' as in this -example: - - * keyboard.c (menu_bar_items, tool_bar_items) - (Fexecute_extended_command): Deal with `keymap' property. - - -File: standards.info, Node: Simple Changes, Next: Conditional Changes, Prev: Style of Change Logs, Up: Change Logs - -6.8.3 Simple Changes --------------------- - -Certain simple kinds of changes don't need much detail in the change -log. - - When you change the calling sequence of a function in a simple -fashion, and you change all the callers of the function to use the new -calling sequence, there is no need to make individual entries for all -the callers that you changed. Just write in the entry for the function -being called, "All callers changed"--like this: - - * keyboard.c (Fcommand_execute): New arg SPECIAL. - All callers changed. - - When you change just comments or doc strings, it is enough to write -an entry for the file, without mentioning the functions. Just "Doc -fixes" is enough for the change log. - - There's no need to make change log entries for documentation files. -This is because documentation is not susceptible to bugs that are hard -to fix. Documentation does not consist of parts that must interact in a -precisely engineered fashion. To correct an error, you need not know -the history of the erroneous passage; it is enough to compare what the -documentation says with the way the program actually works. - - -File: standards.info, Node: Conditional Changes, Next: Indicating the Part Changed, Prev: Simple Changes, Up: Change Logs - -6.8.4 Conditional Changes -------------------------- - -C programs often contain compile-time `#if' conditionals. Many changes -are conditional; sometimes you add a new definition which is entirely -contained in a conditional. It is very useful to indicate in the -change log the conditions for which the change applies. - - Our convention for indicating conditional changes is to use square -brackets around the name of the condition. - - Here is a simple example, describing a change which is conditional -but does not have a function or entity name associated with it: - - * xterm.c [SOLARIS2]: Include string.h. - - Here is an entry describing a new definition which is entirely -conditional. This new definition for the macro `FRAME_WINDOW_P' is -used only when `HAVE_X_WINDOWS' is defined: - - * frame.h [HAVE_X_WINDOWS] (FRAME_WINDOW_P): Macro defined. - - Here is an entry for a change within the function `init_display', -whose definition as a whole is unconditional, but the changes themselves -are contained in a `#ifdef HAVE_LIBNCURSES' conditional: - - * dispnew.c (init_display) [HAVE_LIBNCURSES]: If X, call tgetent. - - Here is an entry for a change that takes affect only when a certain -macro is _not_ defined: - - (gethostname) [!HAVE_SOCKETS]: Replace with winsock version. - - -File: standards.info, Node: Indicating the Part Changed, Prev: Conditional Changes, Up: Change Logs - -6.8.5 Indicating the Part Changed ---------------------------------- - -Indicate the part of a function which changed by using angle brackets -enclosing an indication of what the changed part does. Here is an entry -for a change in the part of the function `sh-while-getopts' that deals -with `sh' commands: - - * progmodes/sh-script.el (sh-while-getopts) <sh>: Handle case that - user-specified option string is empty. - - -File: standards.info, Node: Man Pages, Next: Reading other Manuals, Prev: Change Logs, Up: Documentation - -6.9 Man Pages -============= - -In the GNU project, man pages are secondary. It is not necessary or -expected for every GNU program to have a man page, but some of them do. -It's your choice whether to include a man page in your program. - - When you make this decision, consider that supporting a man page -requires continual effort each time the program is changed. The time -you spend on the man page is time taken away from more useful work. - - For a simple program which changes little, updating the man page may -be a small job. Then there is little reason not to include a man page, -if you have one. - - For a large program that changes a great deal, updating a man page -may be a substantial burden. If a user offers to donate a man page, -you may find this gift costly to accept. It may be better to refuse -the man page unless the same person agrees to take full responsibility -for maintaining it--so that you can wash your hands of it entirely. If -this volunteer later ceases to do the job, then don't feel obliged to -pick it up yourself; it may be better to withdraw the man page from the -distribution until someone else agrees to update it. - - When a program changes only a little, you may feel that the -discrepancies are small enough that the man page remains useful without -updating. If so, put a prominent note near the beginning of the man -page explaining that you don't maintain it and that the Texinfo manual -is more authoritative. The note should say how to access the Texinfo -documentation. - - -File: standards.info, Node: Reading other Manuals, Prev: Man Pages, Up: Documentation - -6.10 Reading other Manuals -========================== - -There may be non-free books or documentation files that describe the -program you are documenting. - - It is ok to use these documents for reference, just as the author of -a new algebra textbook can read other books on algebra. A large portion -of any non-fiction book consists of facts, in this case facts about how -a certain program works, and these facts are necessarily the same for -everyone who writes about the subject. But be careful not to copy your -outline structure, wording, tables or examples from preexisting non-free -documentation. Copying from free documentation may be ok; please check -with the FSF about the individual case. - - -File: standards.info, Node: Managing Releases, Next: References, Prev: Documentation, Up: Top - -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. - -* Menu: - -* Configuration:: How Configuration Should Work -* Makefile Conventions:: Makefile Conventions -* Releases:: Making Releases - - -File: standards.info, Node: Configuration, Next: Makefile Conventions, Up: Managing Releases - -7.1 How Configuration Should Work -================================= - -Each GNU distribution should come with a shell script named -`configure'. This script is given arguments which describe the kind of -machine and system you want to compile the program for. - - The `configure' script must record the configuration options so that -they affect compilation. - - One way to do this is to make a link from a standard name such as -`config.h' to the proper configuration file for the chosen system. If -you use this technique, the distribution should _not_ contain a file -named `config.h'. This is so that people won't be able to build the -program without configuring it first. - - Another thing that `configure' can do is to edit the Makefile. If -you do this, the distribution should _not_ contain a file named -`Makefile'. Instead, it should include a file `Makefile.in' which -contains the input used for editing. Once again, this is so that people -won't be able to build the program without configuring it first. - - If `configure' does write the `Makefile', then `Makefile' should -have a target named `Makefile' which causes `configure' to be rerun, -setting up the same configuration that was set up last time. The files -that `configure' reads should be listed as dependencies of `Makefile'. - - All the files which are output from the `configure' script should -have comments at the beginning explaining that they were generated -automatically using `configure'. This is so that users won't think of -trying to edit them by hand. - - The `configure' script should write a file named `config.status' -which describes which configuration options were specified when the -program was last configured. This file should be a shell script which, -if run, will recreate the same configuration. - - The `configure' script should accept an option of the form -`--srcdir=DIRNAME' to specify the directory where sources are found (if -it is not the current directory). This makes it possible to build the -program in a separate directory, so that the actual source directory is -not modified. - - If the user does not specify `--srcdir', then `configure' should -check both `.' and `..' to see if it can find the sources. If it finds -the sources in one of these places, it should use them from there. -Otherwise, it should report that it cannot find the sources, and should -exit with nonzero status. - - Usually the easy way to support `--srcdir' is by editing a -definition of `VPATH' into the Makefile. Some rules may need to refer -explicitly to the specified source directory. To make this possible, -`configure' can add to the Makefile a variable named `srcdir' whose -value is precisely the specified directory. - - 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, a Sun 3 might be `m68k-sun-sunos4.1'. - - The `configure' script needs to be able to decode all plausible -alternatives for how to describe a machine. Thus, `sun3-sunos4.1' -would be a valid alias. For many programs, `vax-dec-ultrix' would be -an alias for `vax-dec-bsd', simply because the differences between -Ultrix and BSD are rarely noticeable, but a few programs might need to -distinguish them. - - There is a shell script called `config.sub' that you can use as a -subroutine to validate system types and canonicalize aliases. - - Other options are permitted to specify in more detail the software -or hardware present on the machine, and include or exclude optional -parts of the package: - -`--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. - - All `configure' scripts should accept all of these "detail" options, -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. - - You will note that the categories `--with-' and `--enable-' are -narrow: they *do not* provide a place for any sort of option you might -think of. That is deliberate. We want to limit the possible -configuration options in GNU software. We do not want GNU programs to -have idiosyncratic configuration options. - - Packages that perform part of the compilation process may support -cross-compilation. In such a case, the host and target machines for the -program may be different. - - The `configure' script should normally treat the specified type of -system as both the host and the target, thus producing a program which -works for the same type of machine that it runs on. - - 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 HOSTTYPE --target=TARGETTYPE - - 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. - - Bootstrapping a cross-compiler requires compiling it on a machine -other than the host it will run on. Compilation packages accept a -configuration option `--build=BUILDTYPE' for specifying the -configuration on which you will compile them, but the configure script -should normally guess the build machine type (using `config.guess'), so -this option is probably not necessary. The host and target types -normally default from the build type, so in bootstrapping a -cross-compiler you must specify them both explicitly. - - Some programs have ways of configuring themselves automatically. If -your program is set up to do this, your `configure' script can simply -ignore most of its arguments. - - -File: standards.info, Node: Makefile Conventions, Next: Releases, Prev: Configuration, Up: Managing Releases - -7.2 Makefile Conventions -======================== - -This node 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 in Makefiles -* Command Variables:: Variables for Specifying Commands -* 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. - - -File: standards.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up: Makefile Conventions - -7.2.1 General Conventions for Makefiles ---------------------------------------- - -Every Makefile should contain this line: - - SHELL = /bin/sh - -to avoid trouble on systems where the `SHELL' variable might be -inherited from the environment. (This is never a problem with GNU -`make'.) - - Different `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: - - .SUFFIXES: - .SUFFIXES: .c .o - -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 `.' 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 `./' if the program is built as -part of the make or `$(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 `./' (the "build directory") and -`$(srcdir)/' (the "source directory") is important because users can -build in a separate directory using the `--srcdir' option to -`configure'. A rule of the form: - - foo.1 : foo.man sedscript - sed -e sedscript foo.man > foo.1 - -will fail when the build directory is not the source directory, because -`foo.man' and `sedscript' are in the source directory. - - 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 -e $(srcdir)/sedscript $(srcdir)/foo.man > $@ - - 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 `make'. - - -File: standards.info, Node: Utilities in Makefiles, Next: Command Variables, Prev: Makefile Basics, Up: Makefile Conventions - -7.2.2 Utilities in Makefiles ----------------------------- - -Write the Makefile commands (and any shell scripts, such as -`configure') to run in `sh', not in `csh'. Don't use any special -features of `ksh' or `bash'. - - The `configure' script and the Makefile rules for building and -installation should not use any utilities directly except these: - - 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 - - The compression program `gzip' can be used in the `dist' rule. - - Stick to the generally supported options for these programs. For -example, don't use `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 `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.) - - 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: - - chgrp chmod chown mknod - - It is ok to use other utilities in Makefile portions (or scripts) -intended only for particular systems where you know those utilities -exist. - - -File: standards.info, Node: Command Variables, Next: Directory Variables, Prev: Utilities in Makefiles, Up: Makefile Conventions - -7.2.3 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 `BISON' whose default -value is set with `BISON = bison', and refer to it with `$(BISON)' -whenever you need to use Bison. - - File management utilities such as `ln', `rm', `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 `FLAGS' to the -program-name variable name to get the options variable name--for -example, `BISONFLAGS'. (The names `CFLAGS' for the C compiler, -`YFLAGS' for yacc, and `LFLAGS' for lex, are exceptions to this rule, -but we keep them because they are standard.) Use `CPPFLAGS' in any -compilation command that runs the preprocessor, and use `LDFLAGS' in -any compilation command that does linking as well as in any direct use -of `ld'. - - If there are C compiler options that _must_ be used for proper -compilation of certain files, do not include them in `CFLAGS'. Users -expect to be able to specify `CFLAGS' freely themselves. Instead, -arrange to pass the necessary options to the C compiler independently -of `CFLAGS', by writing them explicitly in the compilation commands or -by defining an implicit rule, like this: - - CFLAGS = -g - ALL_CFLAGS = -I. $(CFLAGS) - .c.o: - $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $< - - Do include the `-g' option in `CFLAGS', because that is not -_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 `-O' in the default -value of `CFLAGS' as well. - - Put `CFLAGS' last in the compilation command, after other variables -containing compiler options, so the user can use `CFLAGS' to override -the others. - - `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 `INSTALL', which is the -basic command for installing a file into the system. - - 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 nonexecutables respectively. Use -these variables as follows: - - $(INSTALL_PROGRAM) foo $(bindir)/foo - $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a - - Optionally, you may prepend the value of `DESTDIR' to the target -filename. Doing this allows the installer to create a snapshot of the -installation to be copied onto the real target filesystem later. Do not -set the value of `DESTDIR' in your Makefile, and do not include it in -any installed files. With support for `DESTDIR', the above examples -become: - - $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo - $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a - -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. - - -File: standards.info, Node: Directory Variables, Next: Standard Targets, Prev: Command Variables, Up: Makefile Conventions - -7.2.4 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 are described below. They are based on a standard filesystem -layout; variants of it are used in SVR4, 4.4BSD, GNU/Linux, Ultrix v4, -and other modern operating systems. - - These two variables set the root for the installation. All the other -installation directories should be subdirectories of one of these two, -and nothing should be directly installed into these two directories. - -`prefix' - A prefix used in constructing the default values of the variables - listed below. The default value of `prefix' should be - `/usr/local'. When building the complete GNU system, the prefix - will be empty and `/usr' will be a symbolic link to `/'. (If you - are using Autoconf, write it as `@prefix@'.) - - Running `make install' with a different value of `prefix' from the - one used to build the program should _not_ recompile the program. - -`exec_prefix' - A prefix used in constructing the default values of some of the - variables listed below. The default value of `exec_prefix' should - be `$(prefix)'. (If you are using Autoconf, write it as - `@exec_prefix@'.) - - Generally, `$(exec_prefix)' is used for directories that contain - machine-specific files (such as executables and subroutine - libraries), while `$(prefix)' is used directly for other - directories. - - Running `make install' with a different value of `exec_prefix' - from the one used to build the program should _not_ recompile the - program. - - Executable programs are installed in one of the following -directories. - -`bindir' - The directory for installing executable programs that users can - run. This should normally be `/usr/local/bin', but write it as - `$(exec_prefix)/bin'. (If you are using Autoconf, write it as - `@bindir@'.) - -`sbindir' - The directory for installing executable programs that can be run - from the shell, but are only generally useful to system - administrators. This should normally be `/usr/local/sbin', but - write it as `$(exec_prefix)/sbin'. (If you are using Autoconf, - write it as `@sbindir@'.) - -`libexecdir' - The directory for installing executable programs to be run by other - programs rather than by users. This directory should normally be - `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'. - (If you are using Autoconf, write it as `@libexecdir@'.) - - 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. - - Therefore, here are the variables Makefiles should use to specify -directories: - -`datadir' - The directory for installing 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 - `@datadir@'.) As a special exception, see `$(infodir)' and - `$(includedir)' below. - -`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@'.) - -`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@'.) - -`infodir' - The directory for installing the Info files for this package. By - default, it should be `/usr/local/info', but it should be written - as `$(prefix)/info'. (If you are using Autoconf, write it as - `@infodir@'.) - -`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 `$(prefix)/share/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='${datadir}/emacs/site-lisp' - AC_SUBST(lispdir) - -`includedir' - The directory for installing header files to be included by user - programs with the C `#include' preprocessor directive. This - should normally be `/usr/local/include', but write it as - `$(prefix)/include'. (If you are using Autoconf, write it as - `@includedir@'.) - - Most compilers other than GCC do not look for header files in - directory `/usr/local/include'. So installing the header files - this way is only useful with GCC. Sometimes this is not a problem - because some libraries are only really intended to work with GCC. - But some libraries are intended to work with other compilers. - They should install their header files in two places, one - specified by `includedir' and one specified by `oldincludedir'. - -`oldincludedir' - The directory for installing `#include' header files for use with - compilers other than GCC. This should normally be `/usr/include'. - (If you are using Autoconf, you can write it as `@oldincludedir@'.) - - The Makefile commands should check whether the value of - `oldincludedir' is empty. If it is, they should not try to use - it; they should cancel the second installation of the header files. - - A package should not replace an existing header in this directory - unless the header came from the same package. Thus, if your Foo - package provides a header file `foo.h', then it should install the - header file in the `oldincludedir' directory if either (1) there - is no `foo.h' there or (2) the `foo.h' that exists came from the - Foo package. - - To tell whether `foo.h' came from the Foo package, put a magic - string in the file--part of a comment--and `grep' for that string. - - 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/man', but you should - write it as `$(prefix)/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 Autconf, use `srcdir = @srcdir@'.) - - For example: - - # Common prefix for installation directories. - # NOTE: This directory must exist when you start the install. - prefix = /usr/local - 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 = $(prefix)/info - - 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 `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. - - -File: standards.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions - -7.2.5 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 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. Users who don't - mind being helpless can strip the executables later if they wish. - -`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 `install-strip' target to do that. - - If possible, write the `install' target rule so that it does not - modify anything in the directory where the program was built, - provided `make all' has just been done. This is convenient for - building the program under one user name and installing it under - another. - - The commands should create all the directories in which files are - to be installed, if they don't already exist. This includes the - directories specified as the values of the variables `prefix' and - `exec_prefix', as well as all subdirectories that are needed. One - way to do this is by means of an `installdirs' target as described - below. - - Use `-' before any command for installing a man page, so that - `make' will ignore any errors. This is in case there are systems - that don't have the Unix man page documentation system installed. - - The way to install Info files is to copy them into `$(infodir)' - with `$(INSTALL_DATA)' (*note Command Variables::), and then run - the `install-info' program if it is present. `install-info' is a - program that edits the Info `dir' file to add or update the menu - entry for the given Info file; it is part of the Texinfo package. - Here is a sample rule to install an Info file: - - $(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 - - When writing the `install' target, you must classify all the - commands into three categories: normal ones, "pre-installation" - commands and "post-installation" commands. *Note Install Command - Categories::. - -`uninstall' - Delete all the installed files--the copies that the `install' - target creates. - - 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. *Note Install Command - Categories::. - -`install-strip' - Like `install', but strip the executable files while installing - them. In simple cases, this target can use the `install' target in - a simple way: - - install-strip: - $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \ - install - - But if the package installs scripts as well as real executables, - the `install-strip' target can't just refer to the `install' - target; it has to strip the executables but not the scripts. - - `install-strip' should not strip the executables in the build - directory which are being copied for installation. It should only - strip the copies that are installed. - - Normally we do not recommend stripping an executable unless you - are sure the program has no bugs. However, it can be reasonable - to install a stripped executable for actual execution while saving - the unstripped executable elsewhere in case there is a bug. - -`clean' - Delete all files from the current directory that are normally - created by building the program. 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. - - Delete `.dvi' files here if they are not part of the distribution. - -`distclean' - Delete all files from the current directory 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. - -`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 from the current directory 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. This is the only exception; `maintainer-clean' should - delete everything else that can be rebuilt. - - The `maintainer-clean' target is intended to be used by a - maintainer of the package, not by ordinary users. You may need - special tools to reconstruct some of the files that `make - maintainer-clean' deletes. Since these files are normally - included in the distribution, we don't take care to make them easy - to reconstruct. If you find you need to unpack the full - distribution again, don't blame us. - - To help make users aware of this, the commands for the special - `maintainer-clean' target should start with these two: - - @echo 'This command is intended for maintainers to use; it' - @echo 'deletes files that may need special tools to rebuild.' - -`TAGS' - Update a tags table for this program. - -`info' - Generate any Info files needed. The best way to write the rules - is as follows: - - info: foo.info - - foo.info: foo.texi chap1.texi chap2.texi - $(MAKEINFO) $(srcdir)/foo.texi - - You must define the variable `MAKEINFO' in the Makefile. It should - run the `makeinfo' program, which is part of the Texinfo - distribution. - - Normally a GNU distribution comes with Info files, and that means - the Info files are present in the source directory. Therefore, - the Make rule for an info file should update it in the source - directory. When users build the package, ordinarily Make will not - update the Info files because they will already be up to date. - -`dvi' - Generate DVI files for all Texinfo documentation. For example: - - dvi: foo.dvi - - foo.dvi: foo.texi chap1.texi chap2.texi - $(TEXI2DVI) $(srcdir)/foo.texi - - You must define the variable `TEXI2DVI' in the Makefile. It should - run the program `texi2dvi', which is part of the Texinfo - distribution.(1) Alternatively, write just the dependencies, and - allow GNU `make' to provide the command. - -`dist' - Create a distribution tar file for this program. The tar file - should be set up so that the file names in the tar file start with - a subdirectory name which is the name of the package it is a - distribution for. This name can include the version number. - - For example, the distribution tar file of GCC version 1.40 unpacks - into a subdirectory named `gcc-1.40'. - - The easiest way to do this is to create a subdirectory - appropriately named, use `ln' or `cp' to install the proper files - in it, and then `tar' that subdirectory. - - Compress the tar file with `gzip'. For example, the actual - distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'. - - 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. *Note Making Releases: 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 Texinfo 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', - - # 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. - - ---------- Footnotes ---------- - - (1) `texi2dvi' uses TeX to do the real work of formatting. TeX is -not distributed with Texinfo. - - -File: standards.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions - -7.2.6 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: - - make -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 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0} - on {print $0} - $0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1} - - The resulting file of pre-installation commands is executed as a -shell script as part of installing the binary package. - - -File: standards.info, Node: Releases, Prev: Makefile Conventions, Up: Managing Releases - -7.3 Making Releases -=================== - -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'. - - Building and installing the program should never modify any of the -files contained in the distribution. This means that all the files -that form part of the program in any way must be classified into "source -files" and "non-source files". Source files are written by humans and -never changed automatically; non-source files are produced from source -files by programs under the control of the Makefile. - - The distribution should contain a file named `README' which gives -the name of the package, and a general description of what it does. It -is also good to explain the purpose of each of the first-level -subdirectories in the package, if there are any. The `README' file -should either state the version number of the package, or refer to where -in the package it can be found. - - The `README' file should refer to the file `INSTALL', which should -contain an explanation of the installation procedure. - - The `README' file should also refer to the file which contains the -copying conditions. The GNU GPL, if used, should be in a file called -`COPYING'. If the GNU LGPL is used, it should be in a file called -`COPYING.LIB'. - - Naturally, all the source files must be in the distribution. It is -okay to include non-source files in the distribution, provided they are -up-to-date and machine-independent, so that building the distribution -normally will never modify them. We commonly include non-source files -produced by Bison, `lex', TeX, and `makeinfo'; this helps avoid -unnecessary dependencies between our distributions, so that users can -install whichever packages they want to install. - - Non-source files that might actually be modified by building and -installing the program should *never* be included in the distribution. -So if you do distribute non-source files, always make sure they are up -to date when you make a new distribution. - - Make sure that the directory into which the distribution unpacks (as -well as any subdirectories) are all world-writable (octal mode 777). -This is so that old versions of `tar' which preserve the ownership and -permissions of the files from the tar archive will be able to extract -all the files even if the user is unprivileged. - - Make sure that all the files in the distribution are world-readable. - - Make sure that no file name in the distribution is more than 14 -characters long. Likewise, no file created by building the program -should have a name longer than 14 characters. The reason for this is -that some systems adhere to a foolish interpretation of the POSIX -standard, and refuse to open a longer name, rather than truncating as -they did in the past. - - Don't include any symbolic links in the distribution itself. If the -tar file contains symbolic links, then people cannot even unpack it on -systems that don't support symbolic links. Also, don't use multiple -names for one file in different directories, because certain file -systems cannot handle this and that prevents unpacking the distribution. - - Try to make sure that all the file names will be unique on MS-DOS. A -name on MS-DOS consists of up to 8 characters, optionally followed by a -period and up to three characters. MS-DOS will truncate extra -characters both before and after the period. Thus, `foobarhacker.c' -and `foobarhacker.o' are not ambiguous; they are truncated to -`foobarha.c' and `foobarha.o', which are distinct. - - Include in your distribution a copy of the `texinfo.tex' you used to -test print any `*.texinfo' or `*.texi' files. - - Likewise, if your program uses small GNU software packages like -regex, getopt, obstack, or termcap, include them in the distribution -file. Leaving them out would make the distribution file a little -smaller at the expense of possible inconvenience to a user who doesn't -know what other files to get. - - -File: standards.info, Node: References, Next: Copying This Manual, Prev: Managing Releases, Up: Top - -8 References to Non-Free Software and Documentation -*************************************************** - -A GNU program should not recommend use of any non-free program. We -can't stop some people from writing proprietary programs, or stop other -people from using them, but we can and should avoid helping to -advertise them to new potential customers. Proprietary software is a -social and ethical problem, and the point of GNU is to solve that -problem. - - When a non-free program or system is well known, you can mention it -in passing--that is harmless, since users who might want to use it -probably already know about it. For instance, it is fine to explain -how to build your package on top of some non-free operating system, or -how to use it together with some widely used non-free program. - - However, you should give only the necessary information to help those -who already use the non-free program to use your program with it--don't -give, or refer to, any further information about the proprietary -program, and don't imply that the proprietary program enhances your -program, or that its existence is in any way a good thing. The goal -should be that people already using the proprietary program will get -the advice they need about how to use your free program, while people -who don't already use the proprietary program will not see anything to -lead them to take an interest in it. - - If a non-free program or system is obscure in your program's domain, -your program should not mention or support it at all, since doing so -would tend to popularize the non-free program more than it popularizes -your program. (You cannot hope to find many additional users among the -users of Foobar if the users of Foobar are few.) - - A GNU package should not refer the user to any non-free documentation -for free software. Free documentation that can be included in free -operating systems is essential for completing the GNU system, so it is -a major focus of the GNU Project; to recommend use of documentation -that we are not allowed to use in GNU would undermine the efforts to -get documentation that we can include. So GNU packages should never -recommend non-free documentation. - - -File: standards.info, Node: Copying This Manual, Next: Index, Prev: References, Up: Top - -Appendix A Copying This Manual -****************************** - -* Menu: - -* GNU Free Documentation License:: License for copying this manual - - -File: standards.info, Node: GNU Free Documentation License, Up: Copying This Manual - -Appendix B GNU Free Documentation License -***************************************** - - Version 1.1, March 2000 - - Copyright (C) 2000 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - 0. PREAMBLE - - The purpose of this License is to make a manual, textbook, or other - written document "free" in the sense of freedom: to assure everyone - the effective freedom to copy and redistribute it, with or without - modifying it, either commercially or noncommercially. Secondarily, - this License preserves for the author and publisher a way to get - credit for their work, while not being considered responsible for - modifications made by others. - - This License is a kind of "copyleft", which means that derivative - works of the document must themselves be free in the same sense. - It complements the GNU General Public License, which is a copyleft - license designed for free software. - - We have designed this License in order to use it for manuals for - free software, because free software needs free documentation: a - free program should come with manuals providing the same freedoms - that the software does. But this License is not limited to - software manuals; it can be used for any textual work, regardless - of subject matter or whether it is published as a printed book. - We recommend this License principally for works whose purpose is - instruction or reference. - - - 1. APPLICABILITY AND DEFINITIONS - - This License applies to any manual or other work that contains a - notice placed by the copyright holder saying it can be distributed - under the terms of this License. The "Document", below, refers to - any such manual or work. Any member of the public is a licensee, - and is addressed as "you." - - A "Modified Version" of the Document means any work containing the - Document or a portion of it, either copied verbatim, or with - modifications and/or translated into another language. - - A "Secondary Section" is a named appendix or a front-matter - section of the Document that deals exclusively with the - relationship of the publishers or authors of the Document to the - Document's overall subject (or to related matters) and contains - nothing that could fall directly within that overall subject. - (For example, if the Document is in part a textbook of - mathematics, a Secondary Section may not explain any mathematics.) - The relationship could be a matter of historical connection with - the subject or with related matters, or of legal, commercial, - philosophical, ethical or political position regarding them. - - The "Invariant Sections" are certain Secondary Sections whose - titles are designated, as being those of Invariant Sections, in - the notice that says that the Document is released under this - License. - - The "Cover Texts" are certain short passages of text that are - listed, as Front-Cover Texts or Back-Cover Texts, in the notice - that says that the Document is released under this License. - - A "Transparent" copy of the Document means a machine-readable copy, - represented in a format whose specification is available to the - general public, whose contents can be viewed and edited directly - and straightforwardly with generic text editors or (for images - composed of pixels) generic paint programs or (for drawings) some - widely available drawing editor, and that is suitable for input to - text formatters or for automatic translation to a variety of - formats suitable for input to text formatters. A copy made in an - otherwise Transparent file format whose markup has been designed - to thwart or discourage subsequent modification by readers is not - Transparent. A copy that is not "Transparent" is called "Opaque." - - Examples of suitable formats for Transparent copies include plain - ASCII without markup, Texinfo input format, LaTeX input format, - SGML or XML using a publicly available DTD, and - standard-conforming simple HTML designed for human modification. - Opaque formats include PostScript, PDF, proprietary formats that - can be read and edited only by proprietary word processors, SGML - or XML for which the DTD and/or processing tools are not generally - available, and the machine-generated HTML produced by some word - processors for output purposes only. - - The "Title Page" means, for a printed book, the title page itself, - plus such following pages as are needed to hold, legibly, the - material this License requires to appear in the title page. For - works in formats which do not have any title page as such, "Title - Page" means the text near the most prominent appearance of the - work's title, preceding the beginning of the body of the text. - - 2. VERBATIM COPYING - - You may copy and distribute the Document in any medium, either - commercially or noncommercially, provided that this License, the - copyright notices, and the license notice saying this License - applies to the Document are reproduced in all copies, and that you - add no other conditions whatsoever to those of this License. You - may not use technical measures to obstruct or control the reading - or further copying of the copies you make or distribute. However, - you may accept compensation in exchange for copies. If you - distribute a large enough number of copies you must also follow - the conditions in section 3. - - You may also lend copies, under the same conditions stated above, - and you may publicly display copies. - - 3. COPYING IN QUANTITY - - If you publish printed copies of the Document numbering more than - 100, and the Document's license notice requires Cover Texts, you - must enclose the copies in covers that carry, clearly and legibly, - all these Cover Texts: Front-Cover Texts on the front cover, and - Back-Cover Texts on the back cover. Both covers must also clearly - and legibly identify you as the publisher of these copies. The - front cover must present the full title with all words of the - title equally prominent and visible. You may add other material - on the covers in addition. Copying with changes limited to the - covers, as long as they preserve the title of the Document and - satisfy these conditions, can be treated as verbatim copying in - other respects. - - If the required texts for either cover are too voluminous to fit - legibly, you should put the first ones listed (as many as fit - reasonably) on the actual cover, and continue the rest onto - adjacent pages. - - If you publish or distribute Opaque copies of the Document - numbering more than 100, you must either include a - machine-readable Transparent copy along with each Opaque copy, or - state in or with each Opaque copy a publicly-accessible - computer-network location containing a complete Transparent copy - of the Document, free of added material, which the general - network-using public has access to download anonymously at no - charge using public-standard network protocols. If you use the - latter option, you must take reasonably prudent steps, when you - begin distribution of Opaque copies in quantity, to ensure that - this Transparent copy will remain thus accessible at the stated - location until at least one year after the last time you - distribute an Opaque copy (directly or through your agents or - retailers) of that edition to the public. - - It is requested, but not required, that you contact the authors of - the Document well before redistributing any large number of - copies, to give them a chance to provide you with an updated - version of the Document. - - 4. MODIFICATIONS - - You may copy and distribute a Modified Version of the Document - under the conditions of sections 2 and 3 above, provided that you - release the Modified Version under precisely this License, with - the Modified Version filling the role of the Document, thus - licensing distribution and modification of the Modified Version to - whoever possesses a copy of it. In addition, you must do these - things in the Modified Version: - - A. Use in the Title Page (and on the covers, if any) a title - distinct from that of the Document, and from those of previous - versions (which should, if there were any, be listed in the - History section of the Document). You may use the same title - as a previous version if the original publisher of that version - gives permission. - B. List on the Title Page, as authors, one or more persons or - entities responsible for authorship of the modifications in the - Modified Version, together with at least five of the principal - authors of the Document (all of its principal authors, if it - has less than five). - C. State on the Title page the name of the publisher of the - Modified Version, as the publisher. - D. Preserve all the copyright notices of the Document. - E. Add an appropriate copyright notice for your modifications - adjacent to the other copyright notices. - F. Include, immediately after the copyright notices, a license - notice giving the public permission to use the Modified Version - under the terms of this License, in the form shown in the - Addendum below. - G. Preserve in that license notice the full lists of Invariant - Sections and required Cover Texts given in the Document's - license notice. - H. Include an unaltered copy of this License. - I. Preserve the section entitled "History", and its title, and add - to it an item stating at least the title, year, new authors, and - publisher of the Modified Version as given on the Title Page. - If there is no section entitled "History" in the Document, - create one stating the title, year, authors, and publisher of - the Document as given on its Title Page, then add an item - describing the Modified Version as stated in the previous - sentence. - J. Preserve the network location, if any, given in the Document for - public access to a Transparent copy of the Document, and - likewise the network locations given in the Document for - previous versions it was based on. These may be placed in the - "History" section. You may omit a network location for a work - that was published at least four years before the Document - itself, or if the original publisher of the version it refers - to gives permission. - K. In any section entitled "Acknowledgements" or "Dedications", - preserve the section's title, and preserve in the section all the - substance and tone of each of the contributor acknowledgements - and/or dedications given therein. - L. Preserve all the Invariant Sections of the Document, - unaltered in their text and in their titles. Section numbers - or the equivalent are not considered part of the section titles. - M. Delete any section entitled "Endorsements." Such a section - may not be included in the Modified Version. - N. Do not retitle any existing section as "Endorsements" or to - conflict in title with any Invariant Section. - - If the Modified Version includes new front-matter sections or - appendices that qualify as Secondary Sections and contain no - material copied from the Document, you may at your option - designate some or all of these sections as invariant. To do this, - add their titles to the list of Invariant Sections in the Modified - Version's license notice. These titles must be distinct from any - other section titles. - - You may add a section entitled "Endorsements", provided it contains - nothing but endorsements of your Modified Version by various - parties-for example, statements of peer review or that the text has - been approved by an organization as the authoritative definition - of a standard. - - You may add a passage of up to five words as a Front-Cover Text, - and a passage of up to 25 words as a Back-Cover Text, to the end - of the list of Cover Texts in the Modified Version. Only one - passage of Front-Cover Text and one of Back-Cover Text may be - added by (or through arrangements made by) any one entity. If the - Document already includes a cover text for the same cover, - previously added by you or by arrangement made by the same entity - you are acting on behalf of, you may not add another; but you may - replace the old one, on explicit permission from the previous - publisher that added the old one. - - The author(s) and publisher(s) of the Document do not by this - License give permission to use their names for publicity for or to - assert or imply endorsement of any Modified Version. - - 5. COMBINING DOCUMENTS - - You may combine the Document with other documents released under - this License, under the terms defined in section 4 above for - modified versions, provided that you include in the combination - all of the Invariant Sections of all of the original documents, - unmodified, and list them all as Invariant Sections of your - combined work in its license notice. - - The combined work need only contain one copy of this License, and - multiple identical Invariant Sections may be replaced with a single - copy. If there are multiple Invariant Sections with the same name - but different contents, make the title of each such section unique - by adding at the end of it, in parentheses, the name of the - original author or publisher of that section if known, or else a - unique number. Make the same adjustment to the section titles in - the list of Invariant Sections in the license notice of the - combined work. - - In the combination, you must combine any sections entitled - "History" in the various original documents, forming one section - entitled "History"; likewise combine any sections entitled - "Acknowledgements", and any sections entitled "Dedications." You - must delete all sections entitled "Endorsements." - - 6. COLLECTIONS OF DOCUMENTS - - You may make a collection consisting of the Document and other - documents released under this License, and replace the individual - copies of this License in the various documents with a single copy - that is included in the collection, provided that you follow the - rules of this License for verbatim copying of each of the - documents in all other respects. - - You may extract a single document from such a collection, and - distribute it individually under this License, provided you insert - a copy of this License into the extracted document, and follow - this License in all other respects regarding verbatim copying of - that document. - - 7. AGGREGATION WITH INDEPENDENT WORKS - - A compilation of the Document or its derivatives with other - separate and independent documents or works, in or on a volume of - a storage or distribution medium, does not as a whole count as a - Modified Version of the Document, provided no compilation - copyright is claimed for the compilation. Such a compilation is - called an "aggregate", and this License does not apply to the - other self-contained works thus compiled with the Document, on - account of their being thus compiled, if they are not themselves - derivative works of the Document. - - If the Cover Text requirement of section 3 is applicable to these - copies of the Document, then if the Document is less than one - quarter of the entire aggregate, the Document's Cover Texts may be - placed on covers that surround only the Document within the - aggregate. Otherwise they must appear on covers around the whole - aggregate. - - 8. TRANSLATION - - Translation is considered a kind of modification, so you may - distribute translations of the Document under the terms of section - 4. Replacing Invariant Sections with translations requires special - permission from their copyright holders, but you may include - translations of some or all Invariant Sections in addition to the - original versions of these Invariant Sections. You may include a - translation of this License provided that you also include the - original English version of this License. In case of a - disagreement between the translation and the original English - version of this License, the original English version will prevail. - - 9. TERMINATION - - You may not copy, modify, sublicense, or distribute the Document - except as expressly provided for under this License. Any other - attempt to copy, modify, sublicense or distribute the Document is - void, and will automatically terminate your rights under this - License. However, parties who have received copies, or rights, - from you under this License will not have their licenses - terminated so long as such parties remain in full compliance. - - 10. FUTURE REVISIONS OF THIS LICENSE - - The Free Software Foundation may publish new, revised versions of - the GNU Free Documentation License from time to time. Such new - versions will be similar in spirit to the present version, but may - differ in detail to address new problems or concerns. See - http://www.gnu.org/copyleft/. - - Each version of the License is given a distinguishing version - number. If the Document specifies that a particular numbered - version of this License "or any later version" applies to it, you - have the option of following the terms and conditions either of - that specified version or of any later version that has been - published (not as a draft) by the Free Software Foundation. If - the Document does not specify a version number of this License, - you may choose any version ever published (not as a draft) by the - Free Software Foundation. - - -ADDENDUM: How to use this License for your documents -==================================================== - -To use this License in a document you have written, include a copy of -the License in the document and put the following copyright and license -notices just after the title page: - - Copyright (C) YEAR YOUR NAME. - Permission is granted to copy, distribute and/or modify this document - under the terms of the GNU Free Documentation License, Version 1.1 - or any later version published by the Free Software Foundation; - with the Invariant Sections being LIST THEIR TITLES, with the - Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. - A copy of the license is included in the section entitled "GNU - Free Documentation License." - - If you have no Invariant Sections, write "with no Invariant Sections" -instead of saying which ones are invariant. If you have no Front-Cover -Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being -LIST"; likewise for Back-Cover Texts. - - If your document contains nontrivial examples of program code, we -recommend releasing these examples in parallel under your choice of -free software license, such as the GNU General Public License, to -permit their use in free software. - - -File: standards.info, Node: Index, Prev: Copying This Manual, Up: Top - -Index -***** - - -* Menu: - -* #endif, commenting: Comments. (line 54) -* --help option: Command-Line Interfaces. - (line 119) -* --version option: Command-Line Interfaces. - (line 34) -* -Wall compiler option: Syntactic Conventions. - (line 10) -* accepting contributions: Contributions. (line 6) -* address for bug reports: Command-Line Interfaces. - (line 125) -* ANSI C standard: Standard C. (line 6) -* arbitrary limits on data: Semantics. (line 6) -* autoconf: System Portability. (line 23) -* avoiding proprietary code: Reading Non-Free Code. - (line 6) -* behavior, dependent on program's name: User Interfaces. (line 6) -* binary packages: Install Command Categories. - (line 80) -* bindir: Directory Variables. (line 45) -* braces, in C source: Formatting. (line 6) -* bug reports: Command-Line Interfaces. - (line 125) -* canonical name of a program: Command-Line Interfaces. - (line 41) -* casting pointers to integers: CPU Portability. (line 67) -* change logs: Change Logs. (line 6) -* change logs, conditional changes: Conditional Changes. (line 6) -* change logs, style: Style of Change Logs. - (line 6) -* command-line arguments, decoding: Semantics. (line 46) -* command-line interface: Command-Line Interfaces. - (line 6) -* commenting: Comments. (line 6) -* compatibility with C and POSIX standards: Compatibility. (line 6) -* compiler warnings: Syntactic Conventions. - (line 10) -* conditional changes, and change logs: Conditional Changes. (line 6) -* conditionals, comments for: Comments. (line 54) -* configure: Configuration. (line 6) -* control-L: Formatting. (line 114) -* conventions for makefiles: Makefile Conventions. - (line 6) -* corba: Graphical Interfaces. - (line 16) -* credits for manuals: Manual Credits. (line 6) -* data types, and portability: CPU Portability. (line 6) -* declaration for system functions: System Functions. (line 21) -* documentation: Documentation. (line 6) -* doschk: Names. (line 38) -* downloading this manual: Preface. (line 17) -* error messages: Semantics. (line 19) -* error messages, formatting: Errors. (line 6) -* exec_prefix: Directory Variables. (line 27) -* expressions, splitting: Formatting. (line 77) -* file usage: File Usage. (line 6) -* file-name limitations: Names. (line 38) -* formatting error messages: Errors. (line 6) -* formatting source code: Formatting. (line 6) -* formfeed: Formatting. (line 114) -* function argument, declaring: Syntactic Conventions. - (line 6) -* function prototypes: Standard C. (line 17) -* getopt: Command-Line Interfaces. - (line 6) -* gettext: Internationalization. - (line 6) -* gnome: Graphical Interfaces. - (line 16) -* graphical user interface: Graphical Interfaces. - (line 6) -* gtk: Graphical Interfaces. - (line 6) -* GUILE: Source Language. (line 38) -* implicit int: Syntactic Conventions. - (line 6) -* impossible conditions: Semantics. (line 70) -* internationalization: Internationalization. - (line 6) -* legal aspects: Legal Issues. (line 6) -* legal papers: Contributions. (line 6) -* libexecdir: Directory Variables. (line 58) -* libraries: Libraries. (line 6) -* library functions, and portability: System Functions. (line 6) -* license for manuals: License for Manuals. (line 6) -* lint: Syntactic Conventions. - (line 109) -* long option names: Option Table. (line 6) -* long-named options: Command-Line Interfaces. - (line 12) -* makefile, conventions for: Makefile Conventions. - (line 6) -* malloc return value: Semantics. (line 25) -* man pages: Man Pages. (line 6) -* manual structure: Manual Structure Details. - (line 6) -* memory allocation failure: Semantics. (line 25) -* memory usage: Memory Usage. (line 6) -* message text, and internationalization: Internationalization. - (line 29) -* mmap: Mmap. (line 6) -* multiple variables in a line: Syntactic Conventions. - (line 35) -* names of variables, functions, and files: Names. (line 6) -* NEWS file: NEWS File. (line 6) -* non-POSIX systems, and portability: System Portability. (line 32) -* non-standard extensions: Using Extensions. (line 6) -* NUL characters: Semantics. (line 11) -* open brace: Formatting. (line 6) -* optional features, configure-time: Configuration. (line 76) -* options for compatibility: Compatibility. (line 14) -* output device and program's behavior: User Interfaces. (line 13) -* packaging: Releases. (line 6) -* portability, and data types: CPU Portability. (line 6) -* portability, and library functions: System Functions. (line 6) -* portability, between system types: System Portability. (line 6) -* POSIX compatibility: Compatibility. (line 6) -* POSIXLY_CORRECT, environment variable: Compatibility. (line 21) -* post-installation commands: Install Command Categories. - (line 6) -* pre-installation commands: Install Command Categories. - (line 6) -* prefix: Directory Variables. (line 17) -* program configuration: Configuration. (line 6) -* program design: Design Advice. (line 6) -* program name and its behavior: User Interfaces. (line 6) -* program's canonical name: Command-Line Interfaces. - (line 41) -* programming languges: Source Language. (line 6) -* proprietary programs: Reading Non-Free Code. - (line 6) -* README file: Releases. (line 17) -* references to non-free material: References. (line 6) -* releasing: Managing Releases. (line 6) -* sbindir: Directory Variables. (line 51) -* signal handling: Semantics. (line 59) -* spaces before open-paren: Formatting. (line 71) -* standard command-line options: Command-Line Interfaces. - (line 31) -* standards for makefiles: Makefile Conventions. - (line 6) -* string library functions: System Functions. (line 55) -* syntactic conventions: Syntactic Conventions. - (line 6) -* table of long options: Option Table. (line 6) -* temporary files: Semantics. (line 84) -* temporary variables: Syntactic Conventions. - (line 23) -* texinfo.tex, in a distribution: Releases. (line 73) -* TMPDIR environment variable: Semantics. (line 84) -* trademarks: Trademarks. (line 6) -* where to obtain standards.texi: Preface. (line 17) - - - -Tag Table: -Node: Top696 -Node: Preface1396 -Node: Legal Issues3616 -Node: Reading Non-Free Code4080 -Node: Contributions5808 -Node: Trademarks7962 -Node: Design Advice9025 -Node: Source Language9609 -Node: Compatibility11621 -Node: Using Extensions13249 -Node: Standard C14825 -Node: Conditional Compilation17228 -Node: Program Behavior18527 -Node: Semantics19446 -Node: Libraries24139 -Node: Errors25384 -Node: User Interfaces27165 -Node: Graphical Interfaces28770 -Node: Command-Line Interfaces29805 -Node: Option Table35876 -Node: Memory Usage50885 -Node: File Usage51910 -Node: Writing C52658 -Node: Formatting53508 -Node: Comments57571 -Node: Syntactic Conventions60873 -Node: Names64285 -Node: System Portability66494 -Node: CPU Portability68879 -Node: System Functions72135 -Node: Internationalization77332 -Node: Mmap80485 -Node: Documentation81195 -Node: GNU Manuals82300 -Node: Doc Strings and Manuals87357 -Node: Manual Structure Details88910 -Node: License for Manuals90328 -Node: Manual Credits91302 -Node: Printed Manuals91695 -Node: NEWS File92381 -Node: Change Logs93059 -Node: Change Log Concepts93813 -Node: Style of Change Logs95677 -Node: Simple Changes97712 -Node: Conditional Changes98956 -Node: Indicating the Part Changed100378 -Node: Man Pages100905 -Node: Reading other Manuals102529 -Node: Managing Releases103320 -Node: Configuration104083 -Node: Makefile Conventions110988 -Node: Makefile Basics111794 -Node: Utilities in Makefiles114968 -Node: Command Variables117113 -Node: Directory Variables120690 -Node: Standard Targets131584 -Ref: Standard Targets-Footnote-1142824 -Node: Install Command Categories142924 -Node: Releases147506 -Node: References151594 -Node: Copying This Manual153879 -Node: GNU Free Documentation License154115 -Node: Index173816 - -End Tag Table |