| | 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 | ** Try to get the *.pot files to the Translation Project at least one week |
| | 70 | before a stable release, to give them time to translate them. |
| | 71 | |
| | 72 | ** Tests |
| | 73 | See above. |
| | 74 | |
| | 75 | ** Update the foreign files |
| | 76 | Running `./bootstrap' in the top level should update them all for you. |
| | 77 | This covers PO files too. Sometimes a PO file contains problems that |
| | 78 | causes it to be rejected by recent Gettext releases; please report |
| | 79 | these to the Translation Project. |
| | 80 | |
| | 81 | ** Update NEWS |
| | 82 | The version number, *and* the date of the release (including for |
| | 83 | betas). |
| | 84 | |
| | 85 | ** Update ChangeLog |
| | 86 | Should have an entry similar to `Version 1.49b.'. |
| | 87 | Check all this in once `make distcheck' passes. |
| | 88 | |
| | 89 | ** make alpha |
| | 90 | Running `make alpha' is absolutely perfect for beta releases: it makes |
| | 91 | the tarballs, the xdeltas, and prepares (in /tmp/) a proto |
| | 92 | announcement. It is so neat, that that's what I use anyway for |
| | 93 | genuine releases, but adjusting things by hand (e.g., the urls in the |
| | 94 | announcement file, the ChangeLog which is not needed etc.). |
| | 95 | |
| | 96 | If it fails, you're on your own... |
| | 97 | |
| | 98 | It requires GNU Make. |
| | 99 | |
| | 100 | ** Upload |
| | 101 | Put the tarballs/xdeltas where they should be. Or put it somewhere, |
| | 102 | and send the URL to ftp-upload@gnu.org. |
| | 103 | |
| | 104 | ** Bump the version number |
| | 105 | In configure.ac. Run `make', check this in. |
| | 106 | |
| | 107 | ** Announce |
| | 108 | Complete/fix the announcement file, and send it at least to |
| | 109 | info-gnu@gnu.org (if a real release, or a ``serious beta''), |
| | 110 | bug-bison@gnu.org, help-bison@gnu.org, bison-patches@gnu.org, |
| | 111 | and translation@iro.umontreal.ca. |
| | 112 | |
| | 113 | Send the same announcement on the comp.compilers newsgroup by sending |
| | 114 | email to compilers@iecc.com. Do not make any Cc as the moderator will |
| | 115 | throw away anything cross-posted or Cc'ed. It really needs to be a |
| | 116 | separate message. |
| | 117 | |
| | 118 | |
| | 119 | ----- |
| | 120 | |
| | 121 | Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. |
| | 122 | |
| | 123 | This file is part of GNU Bison. |
| | 124 | |
| | 125 | GNU Bison is free software; you can redistribute it and/or modify |
| | 126 | it under the terms of the GNU General Public License as published by |
| | 127 | the Free Software Foundation; either version 2, or (at your option) |
| | 128 | any later version. |
| | 129 | |
| | 130 | GNU Bison is distributed in the hope that it will be useful, |
| | 131 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| | 132 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| | 133 | GNU General Public License for more details. |
| | 134 | |
| | 135 | You should have received a copy of the GNU General Public License |
| | 136 | along with GNU Bison; see the file COPYING. If not, write to the Free |
| | 137 | Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
| | 138 | 02110-1301, USA. |
projects / bison.git / blame_incremental