new from prep
This commit is contained in:
parent
d78086038e
commit
ee7bc291d5
1 changed files with 32 additions and 13 deletions
|
@ -1,6 +1,6 @@
|
|||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename standards.text
|
||||
@setfilename standards.info
|
||||
@settitle GNU Coding Standards
|
||||
@c %**end of header
|
||||
|
||||
|
@ -34,7 +34,7 @@ by the Free Software Foundation.
|
|||
@sp 10
|
||||
@titlefont{GNU Coding Standards}
|
||||
@author{Richard Stallman}
|
||||
@author{last updated 1 Jul 1992}
|
||||
@author{last updated 16 Jul 1992}
|
||||
@c Note date also appears below.
|
||||
@page
|
||||
|
||||
|
@ -60,7 +60,7 @@ by Free Software Foundation.
|
|||
@node Top, Reading Non-Free Code, (dir), (dir)
|
||||
@top Version
|
||||
|
||||
Last updated 1 Jul 1992.
|
||||
Last updated 16 Jul 1992.
|
||||
@c Note date also appears above.
|
||||
@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
|
||||
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
|
||||
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
|
||||
|
@ -1252,12 +1258,20 @@ fit any naming convention.
|
|||
@chapter Portability As It Applies to GNU
|
||||
|
||||
Much of what is called ``portability'' in the Unix world refers to
|
||||
porting to different Unix versions. This is not relevant to GNU
|
||||
software, because its purpose is to run on top of one 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
|
||||
among GNU systems on different cpu's will be like the variation
|
||||
among Berkeley 4.3 systems on different cpu's.
|
||||
porting to different Unix versions. This is a secondary consideration
|
||||
for GNU software, because its primary purpose is to run on top of one
|
||||
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 among
|
||||
GNU systems on different cpu's will be like the variation among Berkeley
|
||||
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
|
||||
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
|
||||
manual, either the hardcopy or the version in the GNU Emacs Info
|
||||
sub-system (@kbd{C-h i}).
|
||||
|
||||
See existing GNU texinfo files (e.g. those under the @file{man/}
|
||||
directory in the GNU Emacs Distribution) for examples.
|
||||
subsystem (@kbd{C-h i}). See existing GNU Texinfo files (e.g. those
|
||||
under the @file{man/} directory in the GNU Emacs Distribution) for
|
||||
examples.
|
||||
|
||||
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
|
||||
|
@ -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
|
||||
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
|
||||
@chapter Making Releases
|
||||
|
|
Loading…
Add table
Reference in a new issue