2005-04-25 Paul Jakma <paul.jakma@sun.com>

	* HACKING: Add some notes about build system changes, to
	  document common oversights (common for me anyway).
	  Seperate sections with two newlines, easier to read.

1 files changed, 27 insertions, 1 deletions

diff --git a/HACKING b/HACKING
index 849728075..12d96647e 100644
--- a/HACKING
+++ b/HACKING
@@ -1,5 +1,5 @@
 -*- mode: text; -*-
-$Id: HACKING,v 1.19 2005/04/07 07:30:20 paul Exp $
+$Id: HACKING,v 1.20 2005/04/25 00:37:03 paul Exp $
 
 GUIDELINES FOR HACKING ON QUAGGA
 
@@ -61,6 +61,10 @@ To ensure that the core Quagga sources do not use the deprecated interfaces
 while allowing external sources to continue to build. Deprecated interfaces
 should be excised in the next unstable cycle.
 
+Note: If you wish, you can test for GCC and use a function
+marked with the 'deprecated' attribute. However, you must provide the
+#warning for other compilers.
+
 If changing or removing a command definition, *ensure* that you properly
 deprecate it - use the _DEPRECATED form of the appropriate DEFUN macro. This
 is *critical*. Even if the command can no longer function, you *must* still
@@ -71,6 +75,7 @@ release.
 
 See also below regarding SHARED LIBRARY VERSIONING.
 
+
 CHANGELOG
 
 Add a ChangeLog entry whenever changing code, except for minor fixes
@@ -88,6 +93,21 @@ maintainer who usually maintains that meta-data). Also, CVS meta-data such
 as cvsignore files do not require ChangeLog updates, just a sane commit
 message.
 
+
+HACKING THE BUILD SYSTEM
+
+If you change or add to the build system (configure.ac, any Makefile.am,
+etc.), try to check that the following things still work:
+
+	- make dist
+	- resulting dist tarball builds
+	- out-of-tree builds 
+
+The quagga.net site relies on make dist to work to generate snapshots. It
+must work. Commong problems are to forget to have some additional file
+included in the dist, or to have a make rule refer to a source file without
+using the srcdir variable.
+
 RELEASE PROCEDURE
 
   Tag the repository with release tag (follow existing conventions).
@@ -108,12 +128,14 @@ non-standards-conforming tarballs in the past.
 [TODO: collation of a list of deprecated commands. Possibly can be scripted
 to extract from vtysh/vtysh_cmd.c]
 
+
 TOOL VERSIONS
 
 Require versions of support tools are listed in INSTALL.quagga.txt.
 Required versions should only be done with due deliberation, as it can
 cause environments to no longer be able to compile quagga.
 
+
 SHARED LIBRARY VERSIONING
 
 [this section is at the moment just gdt's opinion]
@@ -136,6 +158,7 @@ There is no support intended for installing part of zebra.  The core
 library libzebra and the included daemons should always be built and
 installed together.
 
+
 PATCH SUBMISSION
 
 * Send a clean diff against the head of CVS in unified diff format, eg by:
@@ -161,6 +184,7 @@ PATCH SUBMISSION
   willing to verify -current occasionally, that platform may be
   dropped from the "should be checked" list.
 
+
 PATCH APPLICATION TO CVS
 
 * Only apply patches that meet the submission guidelines.
@@ -181,6 +205,7 @@ PATCH APPLICATION TO CVS
 * By committing a patch, you are responsible for fixing problems
   resulting from it (or backing it out).
 
+
 STABLE PLATFORMS AND DAEMONS
 
 The list of platforms that should be tested follow.  This is a list
@@ -208,6 +233,7 @@ Daemons which are in a testing phase are
   isisd
   watchquagga
 
+
 IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS
 
 The source code of Quagga is based on two vendors: