* doc/autoconf.texi (Limitations of Builtins, Limitations of Make):
[autoconf/tsuna.git] / HACKING
blobf758cf551b6b992e24e4ec877a0cba5f4b0a8dc7
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.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 Free Software Foundation, Inc.
102 This file is part of GNU Autoconf.
104 GNU Autoconf is free software; you can redistribute it and/or modify
105 it under the terms of the GNU General Public License as published by
106 the Free Software Foundation; either version 2, or (at your option)
107 any later version.
109 GNU Autoconf is distributed in the hope that it will be useful, but
110 WITHOUT ANY WARRANTY; without even the implied warranty of
111 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
112 General Public License for more details.
114 You should have received a copy of the GNU General Public License
115 along with GNU Autoconf; see the file COPYING.  If not, write to the
116 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
117 MA 02110-1301, USA.