home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-dist / cvs-1.8.7-src.tgz / tar.out / fsf / cvs / HACKING < prev    next >
Text File  |  1996-09-28  |  5KB  |  113 lines
  1. How to write code for CVS
  2.  
  3. * Compiler options
  4.  
  5. If you are using GCC, you'll want to configure with -Wall, which can
  6. detect many programming errors.  This is not the default because it
  7. might cause spurious warnings, but at least on some machines, there
  8. should be no spurious warnings.  For example:
  9.  
  10.     $ CFLAGS="-g -Wall" ./configure
  11.  
  12. Configure is not very good at remembering this setting; it will get
  13. wiped out whenever you do a ./config.status --recheck, so you'll need
  14. to use:
  15.  
  16.     $ CFLAGS="-g -Wall" ./config.status --recheck
  17.  
  18. * Indentation style
  19.  
  20. CVS mostly uses a consistent indentation style which looks like this:
  21.  
  22. void
  23. foo (arg)
  24.     char *arg;
  25. {
  26.     if (arg != NULL)
  27.     {
  28.     bar (arg);
  29.     baz (arg);
  30.     }
  31. }
  32.  
  33. The file cvs-format.el contains settings for emacs and the NEWS file
  34. contains a set of options for the indent program which I haven't tried
  35. but which are correct as far as I know.  You will find some code which
  36. does not conform to this indentation style; the plan is to reindent it
  37. as those sections of the code are changed (one function at a time,
  38. perhaps).
  39.  
  40. In a submitted patch it is acceptable to refrain from changing the
  41. indentation of large blocks of code to minimize the size of the patch;
  42. the person checking in such a patch should reindent it.
  43.  
  44. * Portability
  45.  
  46. The general rule for portability is that it is only worth including
  47. portability cruft for systems on which people are actually testing and
  48. using new CVS releases.  Without testing, CVS will fail to be portable
  49. for any number of unanticipated reasons.
  50.  
  51. The current consequence of that general rule seems to be that if it
  52. is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
  53. to use it without ifdefs (for example, assert() and void * as long as
  54. you add more casts to and from void * than ANSI requires.  But not
  55. function prototypes).  Such constructs are generally portable enough,
  56. including to NT, OS/2, VMS, etc.
  57.  
  58. * Run-time behaviors
  59.  
  60. Use assert() to check "can't happen" conditions internal to CVS.  We
  61. realize that there are functions in CVS which instead return NULL or
  62. some such value (thus confusing the meaning of such a returned value),
  63. but we want to fix that code.  Of course, bad input data, a corrupt
  64. repository, bad options, etc., should always print a real error
  65. message instead.
  66.  
  67. * Coding standards in general
  68.  
  69. Generally speaking the GNU coding standards are mostly used by CVS
  70. (but see the exceptions mentioned above, such as indentation style,
  71. and perhaps an exception or two we haven't mentioned).  This is the
  72. file standards.text at the GNU FTP sites.
  73.  
  74. Filenames for .c and .h files may contain _ but should not contain -
  75. (the latter causes Visual C++ 2.1 to create makefiles which Visual C++
  76. 4.0 cannot use).
  77.  
  78. * Submitting patches
  79.  
  80. Please include a ChangeLog entry (see the GNU coding standards for
  81. information on writing one) with patches.  Include a description of
  82. what the patch does (sometimes the ChangeLog entry and/or comments in
  83. the code are appropriate for this, but not always)--patches should not
  84. be checked in unless there is some reason for them, and the
  85. description may be helpful if there is a better way to solve the
  86. problem.  In addition to the ChangeLog entry, there should be a change
  87. to the NEWS file in the case of a new feature.
  88.  
  89. If you solve several unrelated problems, submit a separate
  90. patch for each one.  Patches should be tested before submission.  Use
  91. context diffs or unidiffs for patches.
  92.  
  93. Note that all submitted changes may be distributed under the terms of
  94. the GNU Public License, so if you don't like this, don't submit them.
  95. Submit changes to bug-cvs@prep.ai.mit.edu.
  96.  
  97. Generally speaking if you follow the guidelines in this file you can
  98. expect a yes or no answer about whether your patch is accepted.  But
  99. even in this case there is no guarantee because wading through a bunch
  100. of submissions can be time consuming, and noone has volunteered to
  101. offer any such guarantee.  If you don't receive an answer one way or
  102. another within a month, feel free to ask what the status is.  You can,
  103. if you wish, distribute your patch on mailing lists or newsgroups, if
  104. you want to make it available before it gets merged.
  105.  
  106. * What is the schedule for the next release?
  107.  
  108. There isn't one.  That is, upcoming releases are not announced (or
  109. even hinted at, really) until the feature freeze which is
  110. approximately 2 weeks before the final release (at this time test
  111. releases start appearing and are announced on info-cvs).  This is
  112. intentional, to avoid a last minute rush to get new features in.
  113.