]>
Commit | Line | Data |
---|---|---|
1 | -*- outline -*- | |
2 | ||
3 | This file attempts to describe the rules to use when hacking Bison. | |
4 | Don't put this file into the distribution. Don't mention it in the | |
5 | ChangeLog. | |
6 | ||
7 | Everything related to the development of Bison is on Savannah: | |
8 | ||
9 | http://savannah.gnu.org/projects/bison/ | |
10 | ||
11 | ||
12 | * Administrivia | |
13 | ||
14 | ** If you incorporate a change from somebody on the net: | |
15 | First, if it is a large change, you must make sure they have signed | |
16 | the appropriate paperwork. Second, be sure to add their name and | |
17 | email address to THANKS. | |
18 | ||
19 | ** If a change fixes a test, mention the test in the ChangeLog entry. | |
20 | ||
21 | ** Bug reports | |
22 | If somebody reports a new bug, mention his name in the ChangeLog entry | |
23 | and in the test case you write. Put him into THANKS. | |
24 | ||
25 | The correct response to most actual bugs is to write a new test case | |
26 | which demonstrates the bug. Then fix the bug, re-run the test suite, | |
27 | and check everything in. | |
28 | ||
29 | ||
30 | * Hacking | |
31 | ||
32 | ** Visible changes | |
33 | Which include serious bug fixes, must be mentioned in NEWS. | |
34 | ||
35 | ** Translations | |
36 | Only user visible strings are to be translated: error messages, bits | |
37 | of the .output file etc. This excludes impossible error messages | |
38 | (comparable to assert/abort), and all the --trace output which is | |
39 | meant for the maintainers only. | |
40 | ||
41 | ||
42 | * Test suite | |
43 | ||
44 | ** make check | |
45 | Use liberally. | |
46 | ||
47 | ** Release checks | |
48 | Try to run the test suite with more severe conditions before a | |
49 | release: | |
50 | ||
51 | - Configure the package with --enable-gcc-warnings, so that one checks | |
52 | that 1. Bison compiles cleanly, 2. the parsers it produces compile | |
53 | cleanly too. | |
54 | ||
55 | - run `make maintainer-check' which: | |
56 | - runs `valgrind -q bison' to run Bison under Valgrind. | |
57 | - runs the parsers under Valgrind. | |
58 | - runs the test suite with G++ as C compiler... | |
59 | ||
60 | - Change tests/atlocal/CFLAGS to add your preferred options. For | |
61 | instance, `-traditional' to check that the parsers are K&R. Note | |
62 | that it does not make sense for glr.c, which should be ANSI, | |
63 | but currently is actually GNU C, nor for lalr1.cc, which anyway is | |
64 | not exercised yet in the test suite. | |
65 | ||
66 | ||
67 | * Release Procedure | |
68 | ||
69 | ** Tests | |
70 | See above. | |
71 | ||
72 | ** Update the foreign files | |
73 | Running `./bootstrap' in the top level should update them all for you. | |
74 | This covers PO files too. Sometimes a PO file contains problems that | |
75 | causes it to be rejected by recent Gettext releases; please report | |
76 | these to the Translation Project. | |
77 | ||
78 | ** Update NEWS | |
79 | The version number, *and* the date of the release (including for | |
80 | betas). | |
81 | ||
82 | ** Update ChangeLog | |
83 | Should have an entry similar to `Version 1.49b.'. | |
84 | Check all this in once `make distcheck' passes. | |
85 | ||
86 | ** make alpha | |
87 | Running `make alpha' is absolutely perfect for beta releases: it makes | |
88 | the tarballs, the xdeltas, and prepares (in /tmp/) a proto | |
89 | announcement. It is so neat, that that's what I use anyway for | |
90 | genuine releases, but adjusting things by hand (e.g., the urls in the | |
91 | announcement file, the ChangeLog which is not needed etc.). | |
92 | ||
93 | If it fails, you're on your own... | |
94 | ||
95 | It requires GNU Make. | |
96 | ||
97 | ** Upload | |
98 | Put the tarballs/xdeltas where they should be. Or put it somewhere, | |
99 | and send the URL to ftp-upload@gnu.org. | |
100 | ||
101 | ** Bump the version number | |
102 | In configure.ac. Run `make', check this in. | |
103 | ||
104 | ** Announce | |
105 | Complete/fix the announcement file, and send it at least to | |
106 | info-gnu@gnu.org (if a real release, or a ``serious beta''), | |
107 | bug-bison@gnu.org, help-bison@gnu.org, bison-patches@gnu.org, | |
108 | and translation@iro.umontreal.ca. | |
109 | ||
110 | Send the same announcement on the comp.compilers newsgroup by sending | |
111 | email to compilers@iecc.com. Do not make any Cc as the moderator will | |
112 | throw away anything cross-posted or Cc'ed. It really needs to be a | |
113 | separate message. | |
114 | ||
115 | ||
116 | ----- | |
117 | ||
118 | Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc. | |
119 | ||
120 | This file is part of GNU Bison. | |
121 | ||
122 | GNU Bison is free software; you can redistribute it and/or modify | |
123 | it under the terms of the GNU General Public License as published by | |
124 | the Free Software Foundation; either version 2, or (at your option) | |
125 | any later version. | |
126 | ||
127 | GNU Bison is distributed in the hope that it will be useful, | |
128 | but WITHOUT ANY WARRANTY; without even the implied warranty of | |
129 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
130 | GNU General Public License for more details. | |
131 | ||
132 | You should have received a copy of the GNU General Public License | |
133 | along with GNU Bison; see the file COPYING. If not, write to the Free | |
134 | Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA | |
135 | 02111-1307, USA. |