OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

new from prep

This commit is contained in:
K. Richard Pixley 1992-07-23 16:19:10 +00:00
parent d78086038e
commit ee7bc291d5
1 changed files with 32 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
standards.texi
View File

@ -1,6 +1,6 @@
\input texinfo @c -*-texinfo-*- \input texinfo @c -*-texinfo-*-
@c %**start of header @c %**start of header
@setfilename standards.text @setfilename standards.info
@settitle GNU Coding Standards @settitle GNU Coding Standards
@c %**end of header @c %**end of header
@ -34,7 +34,7 @@ by the Free Software Foundation.
@sp 10 @sp 10
@titlefont{GNU Coding Standards} @titlefont{GNU Coding Standards}
@author{Richard Stallman} @author{Richard Stallman}
@author{last updated 1 Jul 1992} @author{last updated 16 Jul 1992}
@c Note date also appears below. @c Note date also appears below.
@page @page
@ -60,7 +60,7 @@ by Free Software Foundation.
@node Top, Reading Non-Free Code, (dir), (dir) @node Top, Reading Non-Free Code, (dir), (dir)
@top Version @top Version
Last updated 1 Jul 1992. Last updated 16 Jul 1992.
@c Note date also appears above. @c Note date also appears above.
@end ifinfo @end ifinfo
@ -202,6 +202,12 @@ comment with the function in the source to explain what it does.
However, sometimes it is useful to write one line to describe the However, sometimes it is useful to write one line to describe the
overall purpose of a large batch of changes. overall purpose of a large batch of changes.
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.
When you change the calling sequence of a function in a simple When you change the calling sequence of a function in a simple
fashion, and you change all the callers of the function, there is no fashion, and you change all the callers of the function, there is no
need to make individual entries for all the callers. Just write in need to make individual entries for all the callers. Just write in
@ -1252,12 +1258,20 @@ fit any naming convention.
@chapter Portability As It Applies to GNU @chapter Portability As It Applies to GNU
Much of what is called ``portability'' in the Unix world refers to Much of what is called ``portability'' in the Unix world refers to
porting to different Unix versions. This is not relevant to GNU porting to different Unix versions. This is a secondary consideration
software, because its purpose is to run on top of one and only for GNU software, because its primary purpose is to run on top of one
one kernel, the GNU kernel, compiled with one and only one C and only one kernel, the GNU kernel, compiled with one and only one C
compiler, the GNU C compiler. The amount and kinds of variation compiler, the GNU C compiler. The amount and kinds of variation among
among GNU systems on different cpu's will be like the variation GNU systems on different cpu's will be like the variation among Berkeley
among Berkeley 4.3 systems on different cpu's. 4.3 systems on different cpu's.
All users today run GNU software on non-GNU systems. So supporting a
variety of non-GNU systems is desirable; simply not paramount.
The easiest way to achieve portability to a reasonable range of systems
is to use Autoconf. It's unlikely that your program needs to know more
information about the host machine than Autoconf can provide, simply
because most of the programs that need such knowledge have already been
written.
It is difficult to be sure exactly what facilities the GNU kernel It is difficult to be sure exactly what facilities the GNU kernel
will provide, since it isn't finished yet. Therefore, assume you can will provide, since it isn't finished yet. Therefore, assume you can
@ -1348,10 +1362,9 @@ option usage information.
Please use Texinfo for documenting GNU programs. See the Texinfo Please use Texinfo for documenting GNU programs. See the Texinfo
manual, either the hardcopy or the version in the GNU Emacs Info manual, either the hardcopy or the version in the GNU Emacs Info
sub-system (@kbd{C-h i}). subsystem (@kbd{C-h i}). See existing GNU Texinfo files (e.g. those
under the @file{man/} directory in the GNU Emacs Distribution) for
See existing GNU texinfo files (e.g. those under the @file{man/} examples.
directory in the GNU Emacs Distribution) for examples.
The title page of the manual should state the version of the program The title page of the manual should state the version of the program
which the manual applies to. The Top node of the manual should also which the manual applies to. The Top node of the manual should also
@ -1366,6 +1379,12 @@ concepts a user will have before reaching that point in the manual.
Address the goals that a user will have in mind, and explain how to Address the goals that a user will have in mind, and explain how to
accomplish them. accomplish them.
In addition to its manual, the package should have a file named
@file{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.
This way, a user upgrading from any previous version can see what
is new.
@node Releases @node Releases
@chapter Making Releases @chapter Making Releases