| 1 | This file attempts to describe the rules to use when hacking Bison. |
| 2 | Don't put this file into the distribution. |
| 3 | |
| 4 | Everything related to the development of Bison is on Savannah: |
| 5 | |
| 6 | http://savannah.gnu.org/projects/bison/ |
| 7 | |
| 8 | |
| 9 | * Administrivia |
| 10 | |
| 11 | ** If you incorporate a change from somebody on the net: |
| 12 | First, if it is a large change, you must make sure they have signed |
| 13 | the appropriate paperwork. Second, be sure to add their name and |
| 14 | email address to THANKS. |
| 15 | |
| 16 | ** If a change fixes a test, mention the test in the commit message. |
| 17 | |
| 18 | ** Bug reports |
| 19 | If somebody reports a new bug, mention his name in the commit message |
| 20 | and in the test case you write. Put him into THANKS. |
| 21 | |
| 22 | The correct response to most actual bugs is to write a new test case |
| 23 | which demonstrates the bug. Then fix the bug, re-run the test suite, |
| 24 | and check everything in. |
| 25 | |
| 26 | |
| 27 | * Hacking |
| 28 | |
| 29 | ** Visible changes |
| 30 | Which include serious bug fixes, must be mentioned in NEWS. |
| 31 | |
| 32 | ** Translations |
| 33 | Only user visible strings are to be translated: error messages, bits |
| 34 | of the .output file etc. This excludes impossible error messages |
| 35 | (comparable to assert/abort), and all the --trace output which is |
| 36 | meant for the maintainers only. |
| 37 | |
| 38 | |
| 39 | * Working from the repository |
| 40 | |
| 41 | These notes intend to help people working on the checked-out sources. |
| 42 | These requirements do not apply when building from a distribution tarball. |
| 43 | |
| 44 | ** Requirements |
| 45 | |
| 46 | We've opted to keep only the highest-level sources in the repository. |
| 47 | This eases our maintenance burden, (fewer merges etc.), but imposes more |
| 48 | requirements on anyone wishing to build from the just-checked-out sources. |
| 49 | For example, you have to use the latest stable versions of the maintainer |
| 50 | tools we depend upon, including: |
| 51 | |
| 52 | - Automake <http://www.gnu.org/software/automake/> |
| 53 | - Autoconf <http://www.gnu.org/software/autoconf/> |
| 54 | - Flex <http://www.gnu.org/software/flex/> |
| 55 | - Gettext <http://www.gnu.org/software/gettext/> |
| 56 | - Gzip <http://www.gnu.org/software/gzip/> |
| 57 | - Perl <http://www.cpan.org/> |
| 58 | - Rsync <http://samba.anu.edu.au/rsync/> |
| 59 | - Tar <http://www.gnu.org/software/tar/> |
| 60 | |
| 61 | Valgrind <http://valgrind.org/> is also highly recommended, if it supports |
| 62 | your architecture. |
| 63 | |
| 64 | Bison is written using Bison grammars, so there are bootstrapping |
| 65 | issues. The bootstrap script attempts to discover when the C code |
| 66 | generated from the grammars is out of date, and to bootstrap with an |
| 67 | out-of-date version of the C code, but the process is not foolproof. |
| 68 | Also, you may run into similar problems yourself if you modify Bison. |
| 69 | |
| 70 | Only building the initial full source tree will be a bit painful. |
| 71 | Later, after synchronizing from the repository a plain 'make' should |
| 72 | be sufficient. Note, however, that when gnulib is updated, running |
| 73 | './bootstrap' again might be needed. |
| 74 | |
| 75 | ** First checkout |
| 76 | |
| 77 | Obviously, if you are reading these notes, you did manage to check out |
| 78 | this package from the repository. For the record, you will find all the |
| 79 | relevant information on: |
| 80 | |
| 81 | http://savannah.gnu.org/git/?group=bison |
| 82 | |
| 83 | Bison uses Git submodules: subscriptions to other Git repositories. |
| 84 | In particular it uses gnulib, the GNU portability library. To ask Git |
| 85 | to perform the first checkout of the submodules, run |
| 86 | |
| 87 | $ git submodule update --init |
| 88 | |
| 89 | Git submodule support is weak before versions 1.6 and later, you |
| 90 | should probably upgrade Git if your version is older. |
| 91 | |
| 92 | The next step is to get other files needed to build, which are |
| 93 | extracted from other source packages: |
| 94 | |
| 95 | $ ./bootstrap |
| 96 | |
| 97 | And there you are! Just |
| 98 | |
| 99 | $ ./configure |
| 100 | $ make |
| 101 | $ make check |
| 102 | |
| 103 | At this point, there should be no difference between your local copy, |
| 104 | and the master copy: |
| 105 | |
| 106 | $ git diff |
| 107 | |
| 108 | should output no difference. |
| 109 | |
| 110 | Enjoy! |
| 111 | |
| 112 | ** Updating |
| 113 | |
| 114 | The use of submodules make things somewhat different because git does |
| 115 | not support recursive operations: submodules must be taken care of |
| 116 | explicitly by the user. |
| 117 | |
| 118 | *** Updating Bison |
| 119 | |
| 120 | If you pull a newer version of a branch, say via "git pull", you might |
| 121 | import requests for updated submodules. A simple "git diff" will |
| 122 | reveal if the current version of the submodule (i.e., the actual |
| 123 | contents of the gnulib directory) and the current request from the |
| 124 | subscriber (i.e., the reference of the version of gnulib that the |
| 125 | Bison repository requests) differ. To upgrade the submodules (i.e., |
| 126 | to check out the version that is actually requested by the subscriber, |
| 127 | run "git submodule update". |
| 128 | |
| 129 | $ git pull |
| 130 | $ git submodule update |
| 131 | |
| 132 | *** Updating a submodule |
| 133 | To update a submodule, say gnulib, do as follows: |
| 134 | |
| 135 | Get the most recent version of the master branch from git. |
| 136 | |
| 137 | $ cd gnulib |
| 138 | $ git fetch |
| 139 | $ git checkout -b master --track origin/master |
| 140 | |
| 141 | Make sure Bison can live with that version of gnulib. |
| 142 | |
| 143 | $ cd .. |
| 144 | $ ./bootstrap |
| 145 | $ make distcheck |
| 146 | |
| 147 | Register your changes. |
| 148 | |
| 149 | $ git checkin ... |
| 150 | |
| 151 | For a suggestion of what gnulib commit might be stable enough for a |
| 152 | formal release, see the ChangeLog in the latest gnulib snapshot at: |
| 153 | |
| 154 | http://erislabs.net/ianb/projects/gnulib/ |
| 155 | |
| 156 | The Autoconf files we use are currently: |
| 157 | |
| 158 | m4/m4.m4 |
| 159 | lib/m4sugar/m4sugar.m4 |
| 160 | lib/m4sugar/foreach.m4 |
| 161 | |
| 162 | These files don't change very often in Autoconf, so it should be |
| 163 | relatively straight-forward to examine the differences in order to |
| 164 | decide whether to update. |
| 165 | |
| 166 | * Test suite |
| 167 | |
| 168 | ** make check |
| 169 | Use liberally. |
| 170 | |
| 171 | ** Typical errors |
| 172 | If the test suite shows failures such as the following one |
| 173 | |
| 174 | .../bison/lib/getopt.h:196:8: error: redefinition of 'struct option' |
| 175 | /usr/include/getopt.h:54:8: error: previous definition of 'struct option' |
| 176 | |
| 177 | it probably means that some file was compiled without |
| 178 | AT_DATA_SOURCE_PROLOGUE. This error is due to the fact that our -I options |
| 179 | pick up gnulib's replacement headers, such as getopt.h, and this will go |
| 180 | wrong if config.h was not included first. |
| 181 | |
| 182 | See tests/local.at for details. |
| 183 | |
| 184 | ** make maintainer-check-valgrind |
| 185 | This target uses valgrind both to check bison, and the generated parsers. |
| 186 | |
| 187 | This is not mature on Mac OS X. First, Valgrind does support the way bison |
| 188 | calls m4, so Valgrind cannot be used to check bison on Mac OS X. |
| 189 | |
| 190 | Second, there are many errors that come from the platform itself, not from |
| 191 | bison. build-aux/darwin11.4.0.valgrind addresses some of them. |
| 192 | |
| 193 | Third, valgrind issues warnings such as: |
| 194 | |
| 195 | --99312:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); |
| 196 | |
| 197 | which cause the test to fail uselessly. It is hard to ignore these errors |
| 198 | with a major overhaul of the way instrumentation is performed in the test |
| 199 | suite. So currently, do not try to run valgrind on Mac OS X. |
| 200 | |
| 201 | ** Release checks |
| 202 | Try to run the test suite with more severe conditions before a |
| 203 | release: |
| 204 | |
| 205 | - Configure the package with --enable-gcc-warnings, so that one checks |
| 206 | that 1. Bison compiles cleanly, 2. the parsers it produces compile |
| 207 | cleanly too. |
| 208 | |
| 209 | - Maybe build with -DGNULIB_POSIXCHECK, which suggests gnulib modules |
| 210 | that can fix portability issues. See if you really want to pay |
| 211 | attention to its warnings; there's no need to obey blindly to it |
| 212 | (<http://lists.gnu.org/archive/html/bison-patches/2012-05/msg00057.html>). |
| 213 | |
| 214 | - Check with "make syntax-check" if there are issues diagnosed by |
| 215 | gnulib. |
| 216 | |
| 217 | - run "make maintainer-check" which: |
| 218 | - runs "valgrind -q bison" to run Bison under Valgrind. |
| 219 | - runs the parsers under Valgrind. |
| 220 | - runs the test suite with G++ as C compiler... |
| 221 | |
| 222 | - run "make maintainer-push-check", which runs "make maintainer-check" |
| 223 | while activating the push implementation and its pull interface wrappers |
| 224 | in many test cases that were originally written to exercise only the |
| 225 | pull implementation. This makes certain the push implementation can |
| 226 | perform every task the pull implementation can. |
| 227 | |
| 228 | - run "make maintainer-xml-check", which runs "make maintainer-check" |
| 229 | while checking Bison's XML automaton report for every working grammar |
| 230 | passed to Bison in the test suite. The check just diffs the output of |
| 231 | Bison's included XSLT style sheets with the output of --report=all and |
| 232 | --graph. |
| 233 | |
| 234 | - running "make maintainer-release-check" takes care of running |
| 235 | maintainer-check, maintainer-push-check and maintainer-xml-check. |
| 236 | |
| 237 | - Change tests/atlocal/CFLAGS to add your preferred options. For |
| 238 | instance, "-traditional" to check that the parsers are K&R. Note |
| 239 | that it does not make sense for glr.c, which should be ANSI, but |
| 240 | currently is actually GNU C, nor for lalr1.cc. |
| 241 | |
| 242 | |
| 243 | * Release Procedure |
| 244 | This section needs to be updated to take into account features from |
| 245 | gnulib. In particular, be sure to read README-release. |
| 246 | |
| 247 | ** Update the submodules. See above. |
| 248 | |
| 249 | ** Update maintainer tools, such as Autoconf. See above. |
| 250 | |
| 251 | ** Try to get the *.pot files to the Translation Project at least one |
| 252 | week before a stable release, to give them time to translate them. |
| 253 | Before generating the *.pot files, make sure that po/POTFILES.in and |
| 254 | runtime-po/POTFILES.in list all files with translatable strings. |
| 255 | This helps: grep -l '\<_(' * |
| 256 | |
| 257 | ** Tests |
| 258 | See above. |
| 259 | |
| 260 | ** Update the foreign files |
| 261 | Running "./bootstrap" in the top level should update them all for you. |
| 262 | This covers PO files too. Sometimes a PO file contains problems that |
| 263 | causes it to be rejected by recent Gettext releases; please report |
| 264 | these to the Translation Project. |
| 265 | |
| 266 | ** Update README |
| 267 | Make sure the information in README is current. Most notably, make sure |
| 268 | it recommends a version of GNU M4 that is compatible with the latest |
| 269 | Bison sources. |
| 270 | |
| 271 | ** Check copyright years. |
| 272 | We update years in copyright statements throughout Bison once at the |
| 273 | start of every year by running "make update-copyright". However, before |
| 274 | a release, it's good to verify that it's actually been run. Besides the |
| 275 | copyright statement for each Bison file, check the copyright statements |
| 276 | that the skeletons insert into generated parsers, and check all |
| 277 | occurrences of PACKAGE_COPYRIGHT_YEAR in configure.ac. |
| 278 | |
| 279 | ** Update NEWS, commit and tag. |
| 280 | See do-release-commit-and-tag in README-release. For a while, we used |
| 281 | beta names such as "2.6_rc1". Now that we use gnulib in the release |
| 282 | procedure, we must use "2.5.90", which has the additional benefit of |
| 283 | being properly sorted in "git tag -l". |
| 284 | |
| 285 | ** make alpha, beta, or stable |
| 286 | See README-release. |
| 287 | |
| 288 | ** Upload |
| 289 | There are two ways to upload the tarballs to the GNU servers: using |
| 290 | gnupload (from gnulib), or by hand. Obviously prefer the former. But |
| 291 | in either case, be sure to read the following paragraph. |
| 292 | |
| 293 | *** Setup |
| 294 | You need "gnupg". |
| 295 | |
| 296 | Make sure your public key has been uploaded at least to |
| 297 | keys.gnupg.net. You can upload it with: |
| 298 | |
| 299 | gpg --keyserver keys.gnupg.net --send-keys F125BDF3 |
| 300 | |
| 301 | where F125BDF3 should be replaced with your key ID. |
| 302 | |
| 303 | *** Using gnupload |
| 304 | You need "ncftp". |
| 305 | |
| 306 | At the end "make stable" (or alpha/beta) will display the procedure to |
| 307 | run. Just copy and paste it in your shell. |
| 308 | |
| 309 | *** By hand |
| 310 | |
| 311 | The generic GNU upload procedure is at: |
| 312 | |
| 313 | http://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads |
| 314 | |
| 315 | Follow the instructions there to register your information so you're permitted |
| 316 | to upload. |
| 317 | |
| 318 | Here's a brief reminder of how to roll the tarballs and upload them: |
| 319 | |
| 320 | *** make distcheck |
| 321 | *** gpg -b bison-2.3b.tar.gz |
| 322 | *** In a file named "bison-2.3b.tar.gz.directive", type: |
| 323 | |
| 324 | version: 1.1 |
| 325 | directory: bison |
| 326 | filename: bison-2.3b.tar.gz |
| 327 | |
| 328 | *** gpg --clearsign bison-2.3b.tar.gz.directive |
| 329 | *** ftp ftp-upload.gnu.org # Log in as anonymous. |
| 330 | *** cd /incoming/alpha # cd /incoming/ftp for full release. |
| 331 | *** put bison-2.3b.tar.gz # This can take a while. |
| 332 | *** put bison-2.3b.tar.gz.sig |
| 333 | *** put bison-2.3b.tar.gz.directive.asc |
| 334 | *** Repeat all these steps for bison-2.3b.tar.xz. |
| 335 | |
| 336 | ** Update Bison manual on www.gnu.org. |
| 337 | |
| 338 | *** You need a non-anonymous checkout of the web pages directory. |
| 339 | |
| 340 | $ cvs -d YOUR_USERID@cvs.savannah.gnu.org:/web/bison checkout bison |
| 341 | |
| 342 | *** Get familiar with the instructions for web page maintainers. |
| 343 | http://www.gnu.org/server/standards/readme_index.html |
| 344 | http://www.gnu.org/server/standards/README.software.html |
| 345 | especially the note about symlinks. |
| 346 | |
| 347 | *** Build the web pages. |
| 348 | Assuming BISON_CHECKOUT refers to a checkout of the Bison dir, and |
| 349 | BISON_WWW_CHECKOUT refers to the web directory created above, do: |
| 350 | |
| 351 | $ cd $BISON_CHECKOUT/doc |
| 352 | $ make stamp-vti |
| 353 | $ ../build-aux/gendocs.sh -o "$BISON_WWW_CHECKOUT/manual" \ |
| 354 | bison "Bison - GNU parser generator" |
| 355 | $ cd $BISON_WWW_CHECKOUT |
| 356 | |
| 357 | Verify that the result looks sane. |
| 358 | |
| 359 | *** Commit the modified and the new files. |
| 360 | |
| 361 | *** Remove old files. |
| 362 | Find the files which have not been overwritten (because they belonged to |
| 363 | sections that have been removed or renamed): |
| 364 | |
| 365 | $ cd manual/html_node |
| 366 | $ ls -lt |
| 367 | |
| 368 | Remove these files and commit their removal to CVS. For each of these |
| 369 | files, add a line to the file .symlinks. This will ensure that |
| 370 | hyperlinks to the removed files will redirect to the entire manual; this |
| 371 | is better than a 404 error. |
| 372 | |
| 373 | There is a problem with 'index.html' being written twice (once for POSIX |
| 374 | function 'index', once for the table of contents); you can ignore this |
| 375 | issue. |
| 376 | |
| 377 | ** Announce |
| 378 | The "make stable" (or alpha/beta) command just created a template, |
| 379 | $HOME/announce-bison-X.Y. Otherwise, to generate it, run: |
| 380 | |
| 381 | make RELEASE_TYPE=alpha gpg_key_ID=F125BDF3 announcement |
| 382 | |
| 383 | where alpha can be replaced by beta or stable and F125BDF3 should be |
| 384 | replaced with your key ID. |
| 385 | |
| 386 | Complete/fix the announcement file. The generated list of recipients |
| 387 | (info-gnu@gnu.org, bug-bison@gnu.org, help-bison@gnu.org, |
| 388 | bison-patches@gnu.org, and coordinator@translationproject.org) is |
| 389 | appropriate for a stable release or a "serious beta". For any other |
| 390 | release, drop at least info-gnu@gnu.org. For an example of how to |
| 391 | fill out the rest of the template, search the mailing list archives |
| 392 | for the most recent release announcement. |
| 393 | |
| 394 | For a stable release, send the same announcement on the comp.compilers |
| 395 | newsgroup by sending email to compilers@iecc.com. Do not make any Cc as |
| 396 | the moderator will throw away anything cross-posted or Cc'ed. It really |
| 397 | needs to be a separate message. |
| 398 | |
| 399 | ** Prepare NEWS |
| 400 | So that developers don't accidentally add new items to the old NEWS |
| 401 | entry, create a new empty entry in line 3 (without the two leading |
| 402 | spaces): |
| 403 | |
| 404 | * Noteworthy changes in release ?.? (????-??-??) [?] |
| 405 | |
| 406 | Push these changes. |
| 407 | |
| 408 | ----- |
| 409 | |
| 410 | Copyright (C) 2002-2005, 2007-2012 Free Software Foundation, Inc. |
| 411 | |
| 412 | This file is part of GNU Bison. |
| 413 | |
| 414 | This program is free software: you can redistribute it and/or modify |
| 415 | it under the terms of the GNU General Public License as published by |
| 416 | the Free Software Foundation, either version 3 of the License, or |
| 417 | (at your option) any later version. |
| 418 | |
| 419 | This program is distributed in the hope that it will be useful, |
| 420 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 421 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 422 | GNU General Public License for more details. |
| 423 | |
| 424 | You should have received a copy of the GNU General Public License |
| 425 | along with this program. If not, see <http://www.gnu.org/licenses/>. |
| 426 | |
| 427 | LocalWords: Automake Autoconf Gettext Gzip Rsync Valgrind gnulib submodules |
| 428 | LocalWords: submodule init cd distcheck checkin ChangeLog valgrind sigreturn |
| 429 | LocalWords: UC gcc DGNULIB POSIXCHECK xml XSLT glr lalr README po runtime rc |
| 430 | LocalWords: gnupload gnupg gpg keyserver BDF ncftp filename clearsign cvs dir |
| 431 | LocalWords: symlinks vti html lt POSIX Cc'ed |
| 432 | |
| 433 | Local Variables: |
| 434 | mode: outline |
| 435 | fill-column: 76 |
| 436 | End: |