103 lines
4.0 KiB
Plaintext
103 lines
4.0 KiB
Plaintext
|
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.
|