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