mirror of
git://git.sv.gnu.org/autoconf
synced 2024-12-09 02:10:22 +08:00
114 lines
3.5 KiB
Plaintext
114 lines
3.5 KiB
Plaintext
-*- outline -*-or
|
|
|
|
This file attempts to describe the rules to use when hacking Autoconf.
|
|
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.
|
|
|
|
** Test fixes
|
|
If a change fixes a test, mention the test in the ChangeLog entry.
|
|
To this end, the Autotest-mode is handy.
|
|
|
|
** Bug reports
|
|
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.
|
|
|
|
** Visible changes
|
|
Which include serious bug fixes, must be mentioned in NEWS.
|
|
|
|
** Portability issues
|
|
Discoveries in portability matters should be written down in the
|
|
documentation (what fails, why it fails, *where* it fails, and what's
|
|
to be written instead?).
|
|
|
|
* Test suite
|
|
|
|
** make check
|
|
Use liberally.
|
|
|
|
** Release checks
|
|
Try to run the test suite with more severe conditions before a
|
|
release:
|
|
|
|
- Run `make maintainer-check'
|
|
This is quite long. It basically runs the test suite using a C++
|
|
compiler instead of a C compiler, and within a severe environment
|
|
(POSIXLY_CORRECT).
|
|
|
|
- Try some real world packages
|
|
Good example is the coreutils package.
|
|
|
|
* Release Procedure
|
|
|
|
** Tests
|
|
See above.
|
|
|
|
** Update the foreign files
|
|
Running `make update' in the top level should make it all for you.
|
|
|
|
** Update configure
|
|
As much as possible, to try an Autoconf that uses itself. That's
|
|
easy: just be in the top level, and run tests/autoconf. Or install
|
|
this autoconf and autoreconf -f.
|
|
|
|
** Update NEWS
|
|
The version number, *and* the date of the release (including for
|
|
betas).
|
|
|
|
** Update ChangeLog
|
|
Should have an entry similar to `Version 2.53b.'.
|
|
Check all this in once `make distcheck' passes.
|
|
|
|
** make alpha
|
|
Running `make alpha' is absolutely perfect for beta releases: it makes
|
|
the tarballs, the xdeltas, and prepares (in /tmp/) a proto
|
|
announcement. It is so neat, that that's what I use anyway for
|
|
genuine releases, but adjusting things by hand (e.g., the urls in the
|
|
announcement file, the ChangeLog which is not needed etc.).
|
|
|
|
If it fails, you're on your own...
|
|
|
|
It requires GNU Make.
|
|
|
|
** Upload
|
|
Put the tarballs/xdeltas where they should be. Or put it somewhere,
|
|
and send the URL to ftp-upload@gnu.org.
|
|
|
|
** Bump the version number
|
|
In configure.ac. Run `make', check this in.
|
|
|
|
** Announce
|
|
Complete/fix the announcement file, and send it at least to
|
|
info@gnu.org (if a real release, or a ``serious beta''),
|
|
autotools-announce@gnu.org (even for ``non serious beta''),
|
|
autoconf@gnu.org, automake@gnu.org, libtool@gnu.org, and
|
|
bug-gnu-utils@gnu.org.
|
|
|
|
|
|
-----
|
|
|
|
Copyright (C) 2002 Free Software Foundation, Inc.
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|