Fix regression in handling VAR=VALUE arguments to testsuite.
[autoconf/ericb.git] / HACKING
blobe6cb3a3acac7c821682d61c23dbb738a7a07c6f7
1 -*- outline -*-or
3 This file attempts to describe the rules to use when hacking Autoconf.
4 Don't put this file into the distribution.  Don't mention it in the
5 ChangeLog.
7 * Administrivia
9 ** If you incorporate a change from somebody on the net:
10 First, if it is a large change, you must make sure they have signed
11 the appropriate paperwork.  Second, be sure to add their name and
12 email address to THANKS.
14 ** Test fixes
15 If a change fixes a test, mention the test in the ChangeLog entry.
16 To this end, the Autotest-mode is handy.
18 ** Bug reports
19 If somebody reports a new bug, mention his name in the ChangeLog entry
20 and in the test case you write.  Put him into THANKS.
22 The correct response to most actual bugs is to write a new test case
23 which demonstrates the bug.  Then fix the bug, re-run the test suite,
24 and check everything in.
26 ** Visible changes
27 Which include serious bug fixes, must be mentioned in NEWS.
29 ** Portability issues
30 Discoveries in portability matters should be written down in the
31 documentation (what fails, why it fails, *where* it fails, and what's
32 to be written instead?).
34 * Test suite
36 ** make check
37 Use liberally.
39 ** Release checks
40 Try to run the test suite with more severe conditions before a
41 release:
43 - Run `make maintainer-check'
44   This is quite long.  It basically runs the test suite using a C++
45   compiler instead of a C compiler, and within a severe environment
46   (POSIXLY_CORRECT).
48 - Try some real world packages
49   Good example is the coreutils package.
51 * Release Procedure
53 ** Tests
54 See above.
56 ** Update the foreign files
57 Running `make update' in the top level should make it all for you.
59 ** Update configure
60 As much as possible, to try an Autoconf that uses itself.  That's
61 easy: just be in the top level, and run tests/autoconf.  Or install
62 this autoconf and autoreconf -f.
64 ** Update NEWS
65 The version number, *and* the date of the release (including for
66 betas).
68 ** Update ChangeLog
69 Should have an entry similar to `Version 2.53b.'.
70 Check all this in once `make distcheck' passes.
72 ** make alpha
73 Running `make alpha' is absolutely perfect for beta releases: it makes
74 the tarballs, the xdeltas, and prepares (in /tmp/) a proto
75 announcement.  It is so neat, that that's what I use anyway for
76 genuine releases, but adjusting things by hand (e.g., the urls in the
77 announcement file, the ChangeLog which is not needed etc.).
79 If it fails, you're on your own...
81 It requires GNU Make.
83 ** Upload
84 Put the tarballs/xdeltas where they should be.  Or put it somewhere,
85 and send the URL to ftp-upload@gnu.org.
87 ** Bump the version number
88 In configure.ac.  Run `make', check this in.
90 ** Announce
91 Complete/fix the announcement file, and send it at least to
92 info-gnu@gnu.org (if a real release, or a ``serious beta''),
93 autotools-announce@gnu.org (even for ``non serious beta''),
94 autoconf@gnu.org, automake@gnu.org, libtool@gnu.org, and
95 bug-gnu-utils@gnu.org.
98 -----
100 Copyright (C) 2002, 2008 Free Software Foundation, Inc.
102 This program is free software: you can redistribute it and/or modify
103 it under the terms of the GNU General Public License as published by
104 the Free Software Foundation, either version 3 of the License, or
105 (at your option) any later version.
107 This program is distributed in the hope that it will be useful,
108 but WITHOUT ANY WARRANTY; without even the implied warranty of
109 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
110 GNU General Public License for more details.
112 You should have received a copy of the GNU General Public License
113 along with this program.  If not, see <http://www.gnu.org/licenses/>.