]> git.saurik.com Git - bison.git/blobdiff - HACKING
Code cleanup.
[bison.git] / HACKING
diff --git a/HACKING b/HACKING
index 091ba66cfc63080d70097f9c8d733933f2ad18a9..f16d4f608e06fd08fbf80ba98385fd4d70e4f500 100644 (file)
--- 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:
 
 
 Everything related to the development of Bison is on Savannah:
 
-       http://savannah.gnu.org/projects/bison/
+        http://savannah.gnu.org/projects/bison/
 
 
 * Administrivia
 
 
 * Administrivia
@@ -47,6 +47,118 @@ of the .output file etc.  This excludes impossible error messages
 meant for the maintainers only.
 
 
 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 <http://www.gnu.org/software/automake/>
+- Autoconf <http://www.gnu.org/software/autoconf/>
+- Flex <http://www.gnu.org/software/flex/>
+- Gettext <http://www.gnu.org/software/gettext/>
+- Gzip <http://www.gnu.org/software/gzip/>
+- Perl <http://www.cpan.org/>
+- Rsync <http://samba.anu.edu.au/rsync/>
+- Tar <http://www.gnu.org/software/tar/>
+
+Valgrind <http://valgrind.org/> 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
 * Test suite
 
 ** make check
@@ -60,6 +172,9 @@ release:
   that 1. Bison compiles cleanly, 2. the parsers it produces compile
   cleanly too.
 
   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.
 - run `make maintainer-check' which:
   - runs `valgrind -q bison' to run Bison under Valgrind.
   - runs the parsers under Valgrind.
@@ -82,6 +197,9 @@ release:
   that it does not make sense for glr.c, which should be ANSI,
   but currently is actually GNU C, nor for lalr1.cc.
 
   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
 
 
 * Release Procedure
 
@@ -98,9 +216,17 @@ causes it to be rejected by recent Gettext releases; please report
 these to the Translation Project.
 
 ** Update README
 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
 
 ** Update NEWS
 The version number, *and* the date of the release (including for
@@ -109,9 +235,6 @@ betas).
 ** Update ChangeLog
 Should have an entry similar to `Version 1.49b.'.
 
 ** 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:
 ** 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:
@@ -145,9 +268,15 @@ The generic GNU upload procedure is at:
 
   http://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads
 
 
   http://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads
 
-After following the instructions there to register your information so you're
-permitted to upload, here's a brief reminder of how to roll the tarballs and
-upload them:
+Follow the instructions there to register your information so you're permitted
+to upload.  Make sure your public key has been uploaded at least to
+keys.gnupg.net.  You can upload it with:
+
+  gpg --keyserver keys.gnupg.net --send-keys F125BDF3
+
+where F125BDF3 should be replaced with your key ID.
+
+Here's a brief reminder of how to roll the tarballs and upload them:
 
 *** make distcheck
 *** gpg -b bison-2.3b.tar.gz
 
 *** make distcheck
 *** gpg -b bison-2.3b.tar.gz
@@ -165,6 +294,47 @@ upload them:
 *** put bison-2.3b.tar.gz.directive.asc
 *** Repeat all these steps for bison-2.3b.tar.bz2.
 
 *** 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:
 
 ** Announce
 To generate a template announcement file:
 
@@ -195,7 +365,7 @@ Push these changes.
 
 -----
 
 
 -----
 
-Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+Copyright (C) 2002-2005, 2007-2010 Free Software Foundation, Inc.
 
 This file is part of GNU Bison.
 
 
 This file is part of GNU Bison.