X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/06c3084fb5a566e802ba35a9cc54be51db7fe6f1..7d424de14c0385012d328642bec6874c8e6cef17:/HACKING diff --git a/HACKING b/HACKING index 10cac90a..1d9dbc63 100644 --- a/HACKING +++ b/HACKING @@ -5,7 +5,7 @@ Don't put this file into the distribution. Everything related to the development of Bison is on Savannah: - http://savannah.gnu.org/projects/bison/ + http://savannah.gnu.org/projects/bison/ * Administrivia @@ -47,6 +47,118 @@ of the .output file etc. This excludes impossible error messages meant for the maintainers only. +* Working from the repository + +These notes intend to help people working on the checked-out sources. +These requirements do not apply when building from a distribution tarball. + +** Requirements + +We've opted to keep only the highest-level sources in the repository. +This eases our maintenance burden, (fewer merges etc.), but imposes more +requirements on anyone wishing to build from the just-checked-out sources. +For example, you have to use the latest stable versions of the maintainer +tools we depend upon, including: + +- Automake +- Autoconf +- Flex +- Gettext +- Gzip +- Perl +- Rsync +- Tar + +Valgrind is also highly recommended, if +Valgrind supports your architecture. + +Bison is written using Bison grammars, so there are bootstrapping +issues. The bootstrap script attempts to discover when the C code +generated from the grammars is out of date, and to bootstrap with an +out-of-date version of the C code, but the process is not foolproof. +Also, you may run into similar problems yourself if you modify Bison. + +Only building the initial full source tree will be a bit painful. +Later, after synchronizing from the repository a plain `make' should +be sufficient. + +** First checkout + +Obviously, if you are reading these notes, you did manage to check out +this package from the repository. For the record, you will find all the +relevant information on: + + http://savannah.gnu.org/git/?group=bison + +Bison uses Git submodules: subscriptions to other Git repositories. +In particular it uses gnulib, the GNU portability library. To ask Git +to perform the first checkout of the submodules, run + + $ git submodule update --init + +Git submodule support is weak before versions 1.6 and later, you +should probably upgrade Git if your version is older. + +The next step is to get other files needed to build, which are +extracted from other source packages: + + $ ./bootstrap + +And there you are! Just + + $ ./configure + $ make + $ make check + +At this point, there should be no difference between your local copy, +and the master copy: + + $ git diff + +should output no difference. + +Enjoy! + +** Updating + +The use of submodules make things somewhat different because git does +not support recursive operations: submodules must be taken care of +explicitly by the user. + +*** Updating Bison + +If you pull a newer version of a branch, say via `git pull', you might +import requests for updated submodules. A simple `git diff' will +reveal if the current version of the submodule (i.e., the actual +contents of the gnulib directory) and the current request from the +subscriber (i.e., the reference of the version of gnulib that the +Bison reporitory requests) differ. To upgrade the submodules (i.e., +to check out the version that is actually requested by the subscriber, +run `git submodule update'. + + $ git pull + $ git submodule update + +*** Updating a submodule +To update a submodule, say gnulib, do as follows: + +Get the most recent version of the master branch from git. + + $ cd gnulib + $ git fetch + $ git checkout -b master --track origin/master + +Make sure Bison can live with that version of gnulib. + + $ cd .. + $ ./bootstrap + $ make distcheck + +Register your changes. + + $ git checkin ... + + * Test suite ** make check @@ -60,6 +172,9 @@ release: that 1. Bison compiles cleanly, 2. the parsers it produces compile cleanly too. +- Build with -DGNULIB_POSIXCHECK. It suggests gnulib modules that can + fix portability issues. + - run `make maintainer-check' which: - runs `valgrind -q bison' to run Bison under Valgrind. - runs the parsers under Valgrind. @@ -82,11 +197,17 @@ release: that it does not make sense for glr.c, which should be ANSI, but currently is actually GNU C, nor for lalr1.cc. +- Test with a very recent version of GCC for both C and C++. Testing + with older versions that are still in use is nice too. + * Release Procedure -** Try to get the *.pot files to the Translation Project at least one week -before a stable release, to give them time to translate them. +** Try to get the *.pot files to the Translation Project at least one +week before a stable release, to give them time to translate them. +Before generating the *.pot files, make sure that po/POTFILES.in and +runtime-po/POTFILES.in list all files with translatable strings. +This helps: grep -l '\<_(' * ** Tests See above. @@ -98,9 +219,17 @@ causes it to be rejected by recent Gettext releases; please report these to the Translation Project. ** Update README -Make sure the information in this file is current. Most notably, make sure it -recommends a version of GNU M4 that is compatible with the latest Bison -sources. +Make sure the information in README is current. Most notably, make sure +it recommends a version of GNU M4 that is compatible with the latest +Bison sources. + +** Check copyright years. +We update years in copyright statements throughout Bison once at the +start of every year by running `make update-copyright'. However, before +a release, it's good to verify that it's actually been run. Besides the +copyright statement for each Bison file, check the copyright statements +that the skeletons insert into generated parsers, and check all +occurrences of PACKAGE_COPYRIGHT_YEAR in configure.ac. ** Update NEWS The version number, *and* the date of the release (including for @@ -109,9 +238,6 @@ betas). ** Update ChangeLog Should have an entry similar to `Version 1.49b.'. -** Update configure.ac -Be sure PACKAGE_COPYRIGHT_YEAR is up-to-date. - ** Tag the release Before Bison will build with the right version number, you must tag the release in git. Do this after all other changes. The command is similar to: @@ -171,14 +297,56 @@ Here's a brief reminder of how to roll the tarballs and upload them: *** put bison-2.3b.tar.gz.directive.asc *** Repeat all these steps for bison-2.3b.tar.bz2. +** Update Bison manual on www.gnu.org. + +*** You need a non-anonymous checkout of the web pages directory. + + $ cvs -d YOUR_USERID@cvs.savannah.gnu.org:/web/bison checkout bison + +*** Get familiar with the instructions for web page maintainers. +http://www.gnu.org/server/standards/readme_index.html +http://www.gnu.org/server/standards/README.software.html +especially the note about symlinks. + +*** Build the web pages. +Assuming BISON_CHECKOUT refers to a checkout of the Bison dir, and +BISON_WWW_CHECKOUT refers to the web directory created above, do: + + $ cd $BISON_CHECKOUT/doc + $ make stamp-vti + $ ../build-aux/gendocs.sh -o "$BISON_WWW_CHECKOUT/manual" \ + bison "Bison - GNU parser generator" + $ cd $BISON_WWW_CHECKOUT + +Verify that the result looks sane. + +*** Commit the modified and the new files. + +*** Remove old files. +Find the files which have not been overwritten (because they belonged to +sections that have been removed or renamed): + + $ cd manual/html_node + $ ls -lt + +Remove these files and commit their removal to CVS. For each of these +files, add a line to the file .symlinks. This will ensure that +hyperlinks to the removed files will redirect to the entire manual; this +is better than a 404 error. + +There is a problem with 'index.html' being written twice (once for POSIX +function 'index', once for the table of contents); you can ignore this +issue. + ** Announce To generate a template announcement file: make RELEASE_TYPE=alpha gpg_key_ID=F125BDF3 announcement -where alpha can be replaced by beta or major and F125BDF3 should be replaced -with your key ID. For an example of how to fill out the template, search the -mailing list archives for the most recent release announcement. +where alpha can be replaced by beta or stable and F125BDF3 should be +replaced with your key ID. For an example of how to fill out the +template, search the mailing list archives for the most recent release +announcement. Complete/fix the announcement file, and send it at least to info-gnu@gnu.org (if a real release, or a ``serious beta''), @@ -201,7 +369,8 @@ Push these changes. ----- -Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc. +Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010 Free +Software Foundation, Inc. This file is part of GNU Bison.