home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 7 / FreshFishVol7.bin / bbs / gnu / gcc-2.3.3-src.lha / GNU / src / amiga / gcc-2.3.3 / gcc.info-8 (.txt) < prev    next >
GNU Info File  |  1994-02-06  |  49KB  |  814 lines
  1. This is Info file gcc.info, produced by Makeinfo-1.49 from the input
  2. file gcc.texi.
  3.    This file documents the use and the internals of the GNU compiler.
  4.    Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
  5.    Permission is granted to make and distribute verbatim copies of this
  6. manual provided the copyright notice and this permission notice are
  7. preserved on all copies.
  8.    Permission is granted to copy and distribute modified versions of
  9. this manual under the conditions for verbatim copying, provided also
  10. that the sections entitled "GNU General Public License" and "Protect
  11. Your Freedom--Fight `Look And Feel'" are included exactly as in the
  12. original, and provided that the entire resulting derived work is
  13. distributed under the terms of a permission notice identical to this
  14.    Permission is granted to copy and distribute translations of this
  15. manual into another language, under the above conditions for modified
  16. versions, except that the sections entitled "GNU General Public
  17. License" and "Protect Your Freedom--Fight `Look And Feel'", and this
  18. permission notice, may be included in translations approved by the Free
  19. Software Foundation instead of in the original English.
  20. File: gcc.info,  Node: Sending Patches,  Prev: Bug Reporting,  Up: Bugs
  21. Sending Patches for GNU CC
  22. ==========================
  23.    If you would like to write bug fixes or improvements for the GNU C
  24. compiler, that is very helpful.  When you send your changes, please
  25. follow these guidelines to avoid causing extra work for us in studying
  26. the patches.
  27.    If you don't follow these guidelines, your information might still be
  28. useful, but using it will take extra work.  Maintaining GNU C is a lot
  29. of work in the best of circumstances, and we can't keep up unless you do
  30. your best to help.
  31.    * Send an explanation with your changes of what problem they fix or
  32.      what improvement they bring about.  For a bug fix, just include a
  33.      copy of the bug report, and explain why the change fixes the bug.
  34.      (Referring to a bug report is not as good as including it, because
  35.      then we will have to look it up, and we have probably already
  36.      deleted it if we've already fixed the bug.)
  37.    * Always include a proper bug report for the problem you think you
  38.      have fixed.  We need to convince ourselves that the change is
  39.      right before installing it.  Even if it is right, we might have
  40.      trouble judging it if we don't have a way to reproduce the problem.
  41.    * Include all the comments that are appropriate to help people
  42.      reading the source in the future understand why this change was
  43.      needed.
  44.    * Don't mix together changes made for different reasons. Send them
  45.      *individually*.
  46.      If you make two changes for separate reasons, then we might not
  47.      want to install them both.  We might want to install just one.  If
  48.      you send them all jumbled together in a single set of diffs, we
  49.      have to do extra work to disentangle them--to figure out which
  50.      parts of the change serve which purpose.  If we don't have time
  51.      for this, we might have to ignore your changes entirely.
  52.      If you send each change as soon as you have written it, with its
  53.      own explanation, then the two changes never get tangled up, and we
  54.      can consider each one properly without any extra work to
  55.      disentangle them.
  56.      Ideally, each change you send should be impossible to subdivide
  57.      into parts that we might want to consider separately, because each
  58.      of its parts gets its motivation from the other parts.
  59.    * Send each change as soon as that change is finished.  Sometimes
  60.      people think they are helping us by accumulating many changes to
  61.      send them all together.  As explained above, this is absolutely
  62.      the worst thing you could do.
  63.      Since you should send each change separately, you might as well
  64.      send it right away.  That gives us the option of installing it
  65.      immediately if it is important.
  66.    * Use `diff -c' to make your diffs.  Diffs without context are hard
  67.      for us to install reliably.  More than that, they make it hard for
  68.      us to study the diffs to decide whether we want to install them. 
  69.      Unidiff format is better than contextless diffs, but not as easy
  70.      to read as `-c' format.
  71.      If you have GNU diff, use `diff -cp', which shows the name of the
  72.      function that each change occurs in.
  73.    * Write the change log entries for your changes.  We get lots of
  74.      changes, and we don't have time to do all the change log writing
  75.      ourselves.
  76.      Read the `ChangeLog' file to see what sorts of information to put
  77.      in, and to learn the style that we use.  The purpose of the change
  78.      log is to show people where to find what was changed.  So you need
  79.      to be specific about what functions you changed; in large
  80.      functions, it's often helpful to indicate where within the
  81.      function the change was.
  82.      On the other hand, once you have shown people where to find the
  83.      change, you need not explain its purpose. Thus, if you add a new
  84.      function, all you need to say about it is that it is new.  If you
  85.      feel that the purpose needs explaining, it probably does--but the
  86.      explanation will be much more useful if you put it in comments in
  87.      the code.
  88.      If you would like your name to appear in the header line for who
  89.      made the change, send us the header line.
  90.    * When you write the fix, keep in mind that we can't install a
  91.      change that would break other systems.
  92.      People often suggest fixing a problem by changing
  93.      machine-independent files such as `toplev.c' to do something
  94.      special that a particular system needs.  Sometimes it is totally
  95.      obvious that such changes would break GNU CC for almost all users.
  96.       We can't possibly make a change like that.  At best it might tell
  97.      us how to write another patch that would solve the problem
  98.      acceptably.
  99.      Sometimes people send fixes that *might* be an improvement in
  100.      general--but it is hard to be sure of this.  It's hard to install
  101.      such changes because we have to study them very carefully.  Of
  102.      course, a good explanation of the reasoning by which you concluded
  103.      the change was correct can help convince us.
  104.      The safest changes are changes to the configuration files for a
  105.      particular machine.  These are safe because they can't create new
  106.      bugs on other machines.
  107.      Please help us keep up with the workload by designing the patch in
  108.      a form that is good to install.
  109. File: gcc.info,  Node: Service,  Next: VMS,  Prev: Bugs,  Up: Top
  110. How To Get Help with GNU CC
  111. ***************************
  112.    If you need help installing, using or changing GNU CC, there are two
  113. ways to find it:
  114.    * Send a message to a suitable network mailing list.  First try
  115.      `bug-gcc@prep.ai.mit.edu', and if that brings no response, try
  116.      `help-gcc@prep.ai.mit.edu'.
  117.    * Look in the service directory for someone who might help you for a
  118.      fee. The service directory is found in the file named `SERVICE' in
  119.      the GNU CC distribution.
  120. File: gcc.info,  Node: VMS,  Next: Portability,  Prev: Service,  Up: Top
  121. Using GNU CC on VMS
  122. *******************
  123. * Menu:
  124. * Include Files and VMS::  Where the preprocessor looks for the include files.
  125. * Global Declarations::    How to do globaldef, globalref and globalvalue with
  126.                            GNU CC.
  127. * VMS Misc::           Misc information.
  128. File: gcc.info,  Node: Include Files and VMS,  Next: Global Declarations,  Up: VMS
  129. Include Files and VMS
  130. =====================
  131.    Due to the differences between the filesystems of Unix and VMS, GNU
  132. CC attempts to translate file names in `#include' into names that VMS
  133. will understand.  The basic strategy is to prepend a prefix to the
  134. specification of the include file, convert the whole filename to a VMS
  135. filename, and then try to open the file.  GNU CC tries various prefixes
  136. one by one until one of them succeeds:
  137.   1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is
  138.      where GNU C header files are traditionally stored.  If you wish to
  139.      store header files in non-standard locations, then you can assign
  140.      the logical `GNU_CC_INCLUDE' to be a s