1 ================================================================
4 * This file attempts to describe the rules to use when hacking
7 * Don't put this file into the distribution. Don't mention it in the
11 ================================================================
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
19 * If a change fixes a test, mention the test in the ChangeLog entry.
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.
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.
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
33 * Changes other than bug fixes must be mentioned in NEWS
36 ================================================================
39 * Always use $(...) and not ${...}
41 * Use `:', not `true'. Use `exit 1', not `false'.
43 * Use `##' comments liberally. Comment anything even remotely
46 * Never use basename or dirname. Instead use sed
48 * If you run `cd' within back-quotes, make sure you set `CDPATH=:',
49 otherwise the directory name may be printed, depending on CDPATH.
51 * For install and uninstall rules, if a loop is required, it should be
52 silent. Then the body of the loop itself should print each
53 "important" comman it runs. The printed commands should be preceded
57 ================================================================
58 = Editing automake.in and aclocal.in
60 * Follow existing indentation style.
62 * Use only Perl 4 constructs
65 ================================================================
68 * Use "make check" and "make maintainer-check" liberally
70 * Make sure each test file is executable
73 ================================================================
76 * Fetch new versions of the files that are maintained by the FSF.
77 Commit. Unfortunately you need an FSF account to do this.
79 * Update NEWS. For an alpha release, update README-alpha.
81 * Update the version number in configure.in.
82 (The idea is that every other alpha number will be a net release.
83 The repository will always have its own "odd" number so we can easily
84 distinguish net and repo versions.)
86 * Configure, build, and install.
88 * Run aclocal, automake, and autoconf.
94 * Put new release on ftp site and send announcement.
95 (If not an alpha, announcement must also go to FSF.)
97 * Update version number in configure.in to next alpha number.
98 Re-run autoconf and commit.