HACKING

   1 ================================================================
   2 = This file
   3
   4 * This file attempts to describe the rules to use when hacking
   5   automake.
   6
   7 * Don't put this file into the distribution.  Don't mention it in the
   8   ChangeLog.
   9
  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 the
  16   appropriate paperwork.
  17   Second, be sure to add their name and email address to THANKS
  18
  19 * If a change fixes a test, mention the test in the ChangeLog entry.
  20
  21 * If somebody reports a new bug, mention his name in the ChangeLog entry
  22   and in the test case you write.  Put him into THANKS.
  23
  24 * The correct response to most actual bugs is to write a new test case
  25   which demonstrates the bug.  Then fix the bug, re-run the test suite,
  26   and check everything in.
  27
  28 * Some files in the automake package are not owned by automake.  These
  29   files should never be edited here.  These files are COPYING, INSTALL,
  30   ansi2knr.1, ansi2knr.c, config.guess config.sub, install-sh, mdate-sh,
  31   missing, mkinstalldirs, texinfo.tex
  32
  33 * Changes other than bug fixes must be mentioned in NEWS
  34
  35
  36 ================================================================
  37 = Editing `.am' files
  38
  39 * Always use $(...) and not ${...}
  40
  41 * Use `:', not `true'.  Use `exit 1', not `false'.
  42
  43 * Use `##' comments liberally.  Comment anything even remotely
  44   unusual.
  45
  46
  47 ================================================================
  48 = Editing automake.in and aclocal.in
  49
  50 * Follow existing indentation style.
  51
  52 * Use only Perl 4 constructs
  53
  54
  55 ================================================================
  56 = Test suite
  57
  58 * Use "make check" and "make maintainer-check" liberally
  59
  60 * Make sure each test file is executable
  61
  62
  63 ================================================================
  64 = Release procedure
  65
  66 * Fetch new versions of the files that are maintained by the FSF.
  67   Commit.  Unfortunately you need an FSF account to do this.
  68
  69 * Update NEWS.  For an alpha release, update README-alpha.
  70
  71 * Update the version number in configure.in.
  72   (The idea is that every other alpha number will be a net release.
  73   The repository will always have its own "odd" number so we can easily
  74   distinguish net and repo versions.)
  75
  76 * Configure, build, and install.
  77
  78 * Run aclocal, automake, and autoconf.
  79
  80 * Commit
  81
  82 * Run `make cvs-dist'
  83
  84 * Put new release on ftp site and send announcement.
  85   (If not an alpha, announcement must also go to FSF.)
  86
  87 * Update version number in configure.in to next alpha number.
  88   Re-run autoconf and commit.