This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: new flag to say when things are instantiated
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: PATCH: new flag to say when things are instantiated
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Wed, 8 Nov 2000 23:10:31 +0000 (GMT)
- cc: Brendan Kehoe <brendan at zen dot org>, <gcc-patches at gcc dot gnu dot org>
[Moved to gcc-patches - the original patch under discussion was sent to
gcc-bugs.]
On Wed, 8 Nov 2000, Phil Edwards wrote:
> On Wed, Nov 08, 2000 at 10:32:02PM +0000, Joseph S. Myers wrote:
> >
> > Surely any new option should come with a patch to invoke.texi to document
> > it? I think documentation for any user-visible features should be
> > considered a necessary part of any patch, not an optional extra.
>
> Yes, *please*. It's extremely frustrating when the most reliable methods
> of learning about a new option are
>
> 1) seeing it used in a makefile, and
> 2) strings(1)'ing the binary occasionally
Could someone with authority to determine the GCC patch submission
procedures please approve the following patch? (Or, at least the first
item concerning documentation, if you feel that the recommendation for
testsuite entries is too strong - perhaps I might be considered biased,
having written over 3000 lines of testcases for GCC.)
--- contribute.html Tue Nov 7 22:36:30 2000
+++ contributenew.html Wed Nov 8 22:59:39 2000
@@ -49,6 +49,16 @@
<ul>
<li> A description of the bug and how your patch fixes this bug. For
new features a description of the feature and your implementation.
+ <li> If the patch adds a new command line option, the patch must
+ also add documentation for that option to the GCC manual.
+ Similarly, if it changes the behavior of an existing command
+ line option or other documented behavior, the patch must update
+ the documentation.</li>
+ <li> It is strongly recommended the patch should add testcases for
+ any new features added and any bugs fixed to the testsuite (if
+ not already there). (You will of course have tested any new
+ features you added, so this is simply a matter of writing your
+ tests in a suitable form for inclusion in the testsuite.)</li>
<li> A ChangeLog entry as plaintext; see the various ChangeLog files
for format and content.<br>
Note that, unlike some other projects, we do require ChangeLogs
--
Joseph S. Myers
jsm28@cam.ac.uk