# HG changeset patch # User Karl Berry # Date 1341160232 25200 # Node ID c845076574971ca4d0e91b3dc05c28af6998307a # Parent 42305131e6fbe7310e97be6327e8efd64266ab3f autoupdate diff --git a/doc/INSTALL b/doc/INSTALL --- a/doc/INSTALL +++ b/doc/INSTALL @@ -124,7 +124,7 @@ installed the package for one architecture, use `make distclean' before reconfiguring for another architecture. - On Mac OS X 10.5 and later systems, you can create libraries and + On MacOS X 10.5 and later systems, you can create libraries and executables that work on multiple system types--known as "fat" or "universal" binaries--by specifying multiple `-arch' options to the compiler but only a single `-arch' option to the preprocessor. Like diff --git a/doc/INSTALL.ISO b/doc/INSTALL.ISO --- a/doc/INSTALL.ISO +++ b/doc/INSTALL.ISO @@ -124,7 +124,7 @@ installed the package for one architecture, use 'make distclean' before reconfiguring for another architecture. - On Mac OS X 10.5 and later systems, you can create libraries and + On MacOS X 10.5 and later systems, you can create libraries and executables that work on multiple system types--known as "fat" or "universal" binaries--by specifying multiple '-arch' options to the compiler but only a single '-arch' option to the preprocessor. Like diff --git a/doc/INSTALL.UTF-8 b/doc/INSTALL.UTF-8 --- a/doc/INSTALL.UTF-8 +++ b/doc/INSTALL.UTF-8 @@ -124,7 +124,7 @@ installed the package for one architecture, use ‘make distclean’ before reconfiguring for another architecture. - On Mac OS X 10.5 and later systems, you can create libraries and + On MacOS X 10.5 and later systems, you can create libraries and executables that work on multiple system types--known as "fat" or "universal" binaries--by specifying multiple ‘-arch’ options to the compiler but only a single ‘-arch’ option to the preprocessor. Like diff --git a/doc/install.texi b/doc/install.texi --- a/doc/install.texi +++ b/doc/install.texi @@ -147,7 +147,7 @@ installed the package for one architecture, use @samp{make distclean} before reconfiguring for another architecture. -On Mac OS X 10.5 and later systems, you can create libraries and +On MacOS X 10.5 and later systems, you can create libraries and executables that work on multiple system types---known as @dfn{fat} or @dfn{universal} binaries---by specifying multiple @option{-arch} options to the compiler but only a single @option{-arch} option to the diff --git a/doc/standards.texi b/doc/standards.texi --- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @setfilename standards.info @settitle GNU Coding Standards @c This date is automagically updated when you save this file: -@set lastupdate June 1, 2012 +@set lastupdate June 30, 2012 @c %**end of header @dircategory GNU organization @@ -3541,6 +3541,16 @@ a change log describes either an individual change or the smallest batch of changes that belong together, also known as a @dfn{change set}. +@cindex title, change log entry +@cindex description, change log entry +For later reference or for summarizing, sometimes it is useful to +start the entry with a one-line description (sometimes called a +@dfn{title}) to describe its overall purpose. + +In the past, we recommended not mentioning changes in non-software +files (manuals, help files, media files, etc.)@: in change logs. +However, we've been advised that it is a good idea to include them, +for the sake of copyright records. The change log file is normally called @file{ChangeLog} and covers an entire directory. Each directory can have its own change log, or a @@ -3552,20 +3562,18 @@ to a @file{ChangeLog} file using @code{rcs2log}; in Emacs, the command @kbd{C-x v a} (@code{vc-update-change-log}) does the job. -There's no need to describe the full purpose of the changes or how -they work together. However, sometimes it is useful to write one line -to describe the overall purpose of a change log entry. If -you think that a change calls for explanation, you're probably right. -Please do explain it---but please put the full 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. - -In the past, we recommended not mentioning changes in non-software -files (manuals, help files, media files, etc.)@: in change logs. -However, we've been advised that it is a good idea to include them, -for the sake of copyright records. +For changes to code, 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 full 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. + +For changes to files that do not support a comment syntax (e.g., media +files), it is ok to include the full explanation in the change log file, +after the title and before the list of individual changes. The easiest way to add an entry to @file{ChangeLog} is with the Emacs command @kbd{M-x add-change-log-entry}. An individual change should