[src/trunk]: src/gnu/dist/binutils these files are created at build time

[mrg <mrg%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/2f41453db370
branches:  trunk
changeset: 571758:2f41453db370
user:      mrg <mrg%NetBSD.org@localhost>
date:      Wed Dec 08 09:47:04 2004 +0000

description:
these files are created at build time

diffstat:

 gnu/dist/binutils/etc/configure.info |   Bin 
 gnu/dist/binutils/etc/standards.info |   341 ++--
 gnu/dist/binutils/gprof/gprof.info   |  2314 +++++++++++++++++++++++++++++++++-
 3 files changed, 2447 insertions(+), 208 deletions(-)

diffs (truncated from 3113 to 300 lines):

diff -r 1390747049a4 -r 2f41453db370 gnu/dist/binutils/etc/configure.info
Binary file gnu/dist/binutils/etc/configure.info has changed
diff -r 1390747049a4 -r 2f41453db370 gnu/dist/binutils/etc/standards.info
--- a/gnu/dist/binutils/etc/standards.info      Wed Dec 08 09:08:53 2004 +0000
+++ b/gnu/dist/binutils/etc/standards.info      Wed Dec 08 09:47:04 2004 +0000
@@ -1,4 +1,4 @@
-This is standards.info, produced by makeinfo version 4.3 from
+This is standards.info, produced by makeinfo version 4.6 from
 ./standards.texi.
 
 START-INFO-DIR-ENTRY
@@ -21,7 +21,7 @@
 Version
 *******
 
-   Last updated February 14, 2002.
+Last updated February 14, 2002.
 
 * Menu:
 
@@ -42,8 +42,8 @@
 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,
+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
@@ -87,7 +87,7 @@
 Keeping Free Software Free
 **************************
 
-   This node discusses how you can make sure that GNU software avoids
+This node discusses how you can make sure that GNU software avoids
 legal difficulties, and other related issues.
 
 * Menu:
@@ -102,8 +102,8 @@
 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.)
+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
@@ -139,7 +139,7 @@
 Accepting Contributions
 =======================
 
-   If the program you are working on is copyrighted by the Free Software
+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
@@ -186,7 +186,7 @@
 Trademarks
 ==========
 
-   Please do not include any trademark acknowledgements in GNU software
+Please do not include any trademark acknowledgements in GNU software
 packages or documentation.
 
    Trademark acknowledgements are the statements that such-and-such is a
@@ -210,7 +210,7 @@
 General Program Design
 **********************
 
-   This node discusses some of the issues you should take into account
+This node discusses some of the issues you should take into account
 when designing your program.
 
 * Menu:
@@ -227,7 +227,7 @@
 Which Languages to Use
 ======================
 
-   When you want to use a language that gets compiled and runs at high
+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
@@ -272,7 +272,7 @@
 Compatibility with Other Implementations
 ========================================
 
-   With occasional exceptions, utility programs and libraries for GNU
+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.
@@ -307,7 +307,7 @@
 Using Non-standard Features
 ===========================
 
-   Many GNU facilities that already exist support a number of convenient
+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.
 
@@ -343,7 +343,7 @@
 Standard C and Pre-Standard C
 =============================
 
-   1989 Standard C is widespread enough now that it is ok to use its
+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.
 
@@ -407,10 +407,10 @@
 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.
+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
 
@@ -452,8 +452,8 @@
 Program Behavior for All Programs
 *********************************
 
-   This node describes conventions for writing robust software.  It
-also describes general standards for error messages, the command line
+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:
@@ -474,11 +474,10 @@
 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.
+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
@@ -573,7 +572,7 @@
 Library Behavior
 ================
 
-   Try to make library functions reentrant.  If they need to do dynamic
+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.
 
@@ -604,7 +603,7 @@
 Formatting Error Messages
 =========================
 
-   Error messages from compilers should look like this:
+Error messages from compilers should look like this:
 
      SOURCE-FILE-NAME:LINENO: MESSAGE
 
@@ -654,9 +653,9 @@
 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.
+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.
@@ -688,7 +687,7 @@
 Standards for Graphical Interfaces
 ==================================
 
-   When you write a program that provides a graphical user interface,
+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").
@@ -710,12 +709,11 @@
 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.
+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
@@ -841,7 +839,7 @@
 Table of Long Options
 =====================
 
-   Here is a table of long options used by GNU programs.  It is surely
+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@localhost> a list of them, with their
@@ -1931,7 +1929,7 @@
 Memory Usage
 ============
 
-   If a program typically uses just a few meg of memory, don't bother
+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
@@ -1954,7 +1952,7 @@
 File Usage
 ==========
 
-   Programs should be prepared to operate when `/usr' and `/etc' are
+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
@@ -1973,7 +1971,7 @@
 Making The Best Use of C
 ************************
 
-   This node provides advice on how best to use the C language when
+This node provides advice on how best to use the C language when
 writing GNU software.
 
 * Menu:
@@ -1994,7 +1992,7 @@
 Formatting Your Source Code
 ===========================
 
-   It is important to put the open-brace that starts the body of a C
+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.
@@ -2113,8 +2111,8 @@
 Commenting Your Work
 ====================
 
-   Every program should start with a comment saying briefly what it is
-for.  Example: `fmt - filter for simple filling of text'.
+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
@@ -2193,7 +2191,7 @@
 Clean Use of C Constructs
 =========================
 
-   Please explicitly declare the types of all objects.  For example, you
+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'.
 
@@ -2306,7 +2304,7 @@
 Naming Variables, Functions, and Files
 ======================================
 
-   The names of global variables and functions in a program serve as
+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
@@ -2355,7 +2353,7 @@
 Portability between System Types
 ================================
 
-   In the Unix world, "portability" refers to porting to different Unix
+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.
 
@@ -2405,7 +2403,7 @@
 Portability between CPUs
 ========================