diff options
author | peter <peter@FreeBSD.org> | 1996-08-20 23:46:10 +0000 |
---|---|---|
committer | peter <peter@FreeBSD.org> | 1996-08-20 23:46:10 +0000 |
commit | 8982e501c77217c860f79bba431f46a62b607a21 (patch) | |
tree | 70187fdf5be4cbefd0baf46bddac7e5e32c13c24 /contrib/cvs/HACKING | |
parent | 01ee40fd6a76f6ff7ef247fc1b2cf6e337f216c5 (diff) | |
download | FreeBSD-src-8982e501c77217c860f79bba431f46a62b607a21.zip FreeBSD-src-8982e501c77217c860f79bba431f46a62b607a21.tar.gz |
Import of slightly trimmed cvs-1.8 distribution. Generated files
and non-unix code has been left out.
Diffstat (limited to 'contrib/cvs/HACKING')
-rw-r--r-- | contrib/cvs/HACKING | 102 |
1 files changed, 102 insertions, 0 deletions
diff --git a/contrib/cvs/HACKING b/contrib/cvs/HACKING new file mode 100644 index 0000000..ac4cdd1 --- /dev/null +++ b/contrib/cvs/HACKING @@ -0,0 +1,102 @@ +How to write code for CVS + +* Compiler options + +If you are using GCC, you'll want to configure with -Wall, which can +detect many programming errors. This is not the default because it +might cause spurious warnings, but at least on some machines, there +should be no spurious warnings. For example: + + $ CFLAGS="-g -Wall" ./configure + +Configure is not very good at remembering this setting; it will get +wiped out whenever you do a ./config.status --recheck, so you'll need +to use: + + $ CFLAGS="-g -Wall" ./config.status --recheck + +* Indentation style + +CVS mostly uses a consistent indentation style which looks like this: + +void +foo (arg) + char *arg; +{ + if (arg != NULL) + { + bar (arg); + baz (arg); + } +} + +The file cvs-format.el contains settings for emacs and the NEWS file +contains a set of options for the indent program which I haven't tried +but which are correct as far as I know. You will find some code which +does not conform to this indentation style; the plan is to reindent it +as those sections of the code are changed (one function at a time, +perhaps). + +In a submitted patch it is acceptable to refrain from changing the +indentation of large blocks of code to minimize the size of the patch; +the person checking in such a patch should reindent it. + +* Portability + +If it is in ANSI C and it is in SunOS4 (using /bin/cc), generally it +is OK to use it without ifdefs (for example, assert() and void * as +long as you add more casts to and from void * than ANSI requires. But +not function prototypes). Such constructs are generally portable +enough, including to NT, OS/2, VMS, etc. + +* Run-time behaviors + +Use assert() to check "can't happen" conditions internal to CVS. We +realize that there are functions in CVS which instead return NULL or +some such value (thus confusing the meaning of such a returned value), +but we want to fix that code. Of course, bad input data, a corrupt +repository, bad options, etc., should always print a real error +message instead. + +* Coding standards in general + +Generally speaking the GNU coding standards are mostly used by CVS +(but see the exceptions mentioned above, such as indentation style, +and perhaps an exception or two we haven't mentioned). This is the +file standards.text at the GNU FTP sites. + +* Submitting patches + +Please include a ChangeLog entry (see the GNU coding standards for +information on writing one) with patches. Include a description of +what the patch does (sometimes the ChangeLog entry and/or comments in +the code are appropriate for this, but not always)--patches should not +be checked in unless there is some reason for them, and the +description may be helpful if there is a better way to solve the +problem. In addition to the ChangeLog entry, there should be a change +to the NEWS file in the case of a new feature. + +If you solve several unrelated problems, submit a separate +patch for each one. Patches should be tested before submission. Use +context diffs or unidiffs for patches. + +Note that all submitted changes may be distributed under the terms of +the GNU Public License, so if you don't like this, don't submit them. +Submit changes to bug-cvs@prep.ai.mit.edu. + +Generally speaking if you follow the guidelines in this file you can +expect a yes or no answer about whether your patch is accepted. But +even in this case there is no guarantee because wading through a bunch +of submissions can be time consuming, and noone has volunteered to +offer any such guarantee. If you don't receive an answer one way or +another within a month, feel free to ask what the status is. You can, +if you wish, distribute your patch on mailing lists or newsgroups, if +you want to make it available before it gets merged. + +* What is the schedule for the next release? + +There isn't one. That is, upcoming releases are not announced (or +even hinted at, really) until the feature freeze which is +approximately 2 weeks before the final release (at this time test +releases start appearing and are announced on info-cvs). This is +intentional, to avoid a last minute rush to get new features in. |