[PATCH 1/3] maint: Merge HACKING and README-hacking

It makes no sense to have two files that describe things that
only apply to a git checkout, when only one will do.

Signed-off-by: Eric Blake <[email protected]>
---
 HACKING        | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 README-hacking | 139 ---------------------------------------------------------
 2 files changed, 128 insertions(+), 145 deletions(-)
 delete mode 100644 README-hacking

diff --git a/HACKING b/HACKING
index 7ce33d2..07d7bcd 100644
--- a/HACKING
+++ b/HACKING
@@ -1,10 +1,130 @@
 -*- outline -*-

-This file attempts to describe the maintainer-specific notes to follow
-when hacking Autoconf.  Don't put this file into the distribution.
-Don't mention it in the ChangeLog.  You may want to first see
-README-hacking for more general rules on building Autoconf from
-checked-out sources.
+These notes intend to help people working on the checked-out sources,
+including maintainer-specific notes for making a release tarball.
+These requirements do not apply when building from a distribution
+tarball.  Don't put this file into the distribution.
+
+* Requirements
+
+We've opted to keep only the highest-level sources in the GIT repository.
+This eases our maintenance burden, (fewer merges etc.), but imposes more
+requirements on anyone wishing to build from the just-checked-out sources.
+For example, you have to use recent stable versions of the maintainer
+tools we depend upon, including:
+
+- Autoconf 2.60+ <http://www.gnu.org/software/autoconf/>
+- Automake 1.10+ <http://www.gnu.org/software/automake/>
+- Help2man 1.29+ <http://www.gnu.org/software/help2man/>
+- M4 1.4.6+ <http://www.gnu.org/software/m4/>
+- Perl 5.006+ <http://www.cpan.org/>
+- Texinfo 4.8+ <http://www.gnu.org/software/texinfo/>
+
+The following are useful as well, if you want to be able to run commands
+like "make dist-lzma" or "make distcheck":
+
+- Gzip <http://www.gnu.org/software/gzip/>
+- Tar <http://www.gnu.org/software/tar/>
+- LZMA Utils 4.32+ <http://tukaani.org/lzma/>
+
+Although we try to keep the CVS mirror of the git repository usable,
+some of the tests in the testsuite will fail if git was not used to
+generate the version string.  Therefore, we recommend:
+
+- Git 1.4.4+ <http://git.or.cz/>
+
+You may find it useful to install the git-merge-changelog merge driver:
+http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
+
+then add the following to .git/config or ~/.gitconfig:
+[merge "merge-changelog"]
+	name = GNU ChangeLog merge driver
+	driver = git-merge-changelog %O %A %B
+[diff "texinfo"]
+	funcname = ^@node[\t ][\t ]*\\([^,][^,]*\\)
+
+Only building the initial full source tree will be a bit painful.
+Later, a plain `git pull && make' should be sufficient.
+
+If you want to test Autoconf on a machine without git, it may be
+easier to first bootstrap Autoconf on a different machine with git,
+run `make dist', and copy the tarball to the machine under test.  It
+should always be possible to create a self-contained tarball which
+does not rely on the bootstrap-only tools.
+
+* First GIT checkout
+
+You can get an anonymous copy of the source repository using any one
+of these three methods, although the CVS mirror is less tested:
+
+  $ git clone git://git.sv.gnu.org/autoconf
+  $ git clone http://git.sv.gnu.org/r/autoconf.git
+  $ cvs -d:pserver:[email protected]:/srv/git/autoconf.git \
+      co -d autoconf HEAD
+
+If you have a Savannah user name and commit rights to the Autoconf
+project, you should use this instead:
+
+  $ git clone <username>@git.sv.gnu.org:/srv/git/autoconf.git
+
+The next step is to generate files like configure and Makefile.in:
+
+  $ cd autoconf
+  $ autoreconf -vi
+
+Since we're building autoconf itself, and its tests are picky, the
+following procedure includes an extra step to ensure that some
+generated files are regenerated using the tools just built by "make"
+(if you use GNU make, the file GNUmakefile sets PATH for you):
+
+  $ ./configure
+  $ make
+  $ ( PATH=`pwd`/tests:$PATH; autoreconf -vi )
+  $ make check
+
+At this point, there should be no difference between your local copy,
+and the GIT master copy:
+
+  $ git diff
+
+should output no difference.
+
+The testsuite is run by 'make check'.  You may find it useful to run a
+subset of the testsuite; for example, all tests with the 'm4sugar'
+keyword as well as test 10:
+
+  $ make check TESTSUITEFLAGS='10 -k m4sugar'
+
+You can pass options to configure scripts invoked by the testsuite by
+setting the configure_options variable:
+
+  $ make check TESTSUITEFLAGS='configure_options="CC=gcc-2.95"'
+
+* Submitting patches
+
+All patches should be submitted to <[email protected]> for
+review, in context or unified diff format against the latest sources.
+In most cases, a patch should include a test case, to ensure that
+regressions do not creep back in.  Remember to add documentation and a
+NEWS entry for anything that is visible to the user.
+
+If your change is significant (i.e., if it adds more than ~10 lines),
+then you'll have to have a copyright assignment on file with the FSF.
+Since that involves first an email exchange between you and the FSF,
+and then the exchange (FSF to you, then back) of an actual sheet of paper
+with your signature on it, and finally, some administrative processing
+in Boston, the process can take a few weeks.
+
+The forms to choose from are in gnulib's doc/Copyright/ directory.
+If you want to assign a single change, you should use the file,
+doc/Copyright/request-assign.changes:
+
+    http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.changes;hb=HEAD
+
+If you would like to assign past and future autoconf work,
+you'd use doc/Copyright/request-assign.future:
+
+    http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD

 * Administrivia

@@ -157,9 +277,11 @@ Update the Free Software Directory: browse to:
 and send an email to <[email protected]> mentioning any content
 that needs to be updated.

+Enjoy!
+
 -----

-Copyright (C) 2002, 2008-2016 Free Software Foundation, Inc.
+Copyright (C) 2002-2016 Free Software Foundation, Inc.

 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
diff --git a/README-hacking b/README-hacking
deleted file mode 100644
index ec2e215..0000000
--- a/README-hacking
+++ /dev/null
@@ -1,139 +0,0 @@
--*- outline -*-
-
-These notes intend to help people working on the checked-out sources.
-These requirements do not apply when building from a distribution
-tarball.  Don't put this file into the distribution.  Don't mention it
-in the ChangeLog.  You may want to also see HACKING for
-maintainer-specific rules.
-
-* Requirements
-
-We've opted to keep only the highest-level sources in the GIT repository.
-This eases our maintenance burden, (fewer merges etc.), but imposes more
-requirements on anyone wishing to build from the just-checked-out sources.
-For example, you have to use recent stable versions of the maintainer
-tools we depend upon, including:
-
-- Autoconf 2.60+ <http://www.gnu.org/software/autoconf/>
-- Automake 1.10+ <http://www.gnu.org/software/automake/>
-- Help2man 1.29+ <http://www.gnu.org/software/help2man/>
-- M4 1.4.6+ <http://www.gnu.org/software/m4/>
-- Perl 5.006+ <http://www.cpan.org/>
-- Texinfo 4.8+ <http://www.gnu.org/software/texinfo/>
-
-The following are useful as well, if you want to be able to run commands
-like "make dist-lzma" or "make distcheck":
-
-- Gzip <http://www.gnu.org/software/gzip/>
-- Tar <http://www.gnu.org/software/tar/>
-- LZMA Utils 4.32+ <http://tukaani.org/lzma/>
-
-Although we try to keep the CVS mirror of the git repository usable,
-some of the tests in the testsuite will fail if git was not used to
-generate the version string.  Therefore, we recommend:
-
-- Git 1.4.4+ <http://git.or.cz/>
-
-You may find it useful to install the git-merge-changelog merge driver:
-http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
-then add the following to .git/config or ~/.gitconfig:
-[merge "merge-changelog"]
-	name = GNU ChangeLog merge driver
-	driver = git-merge-changelog %O %A %B
-[diff "texinfo"]
-	funcname = ^@node[\t ][\t ]*\\([^,][^,]*\\)
-
-Only building the initial full source tree will be a bit painful.
-Later, a plain `git pull && make' should be sufficient.
-
-If you want to test Autoconf on a machine without git, it may be
-easier to first bootstrap Autoconf on a different machine with git,
-run `make dist', and copy the tarball to the machine under test.  It
-should always be possible to create a self-contained tarball which
-does not rely on the bootstrap-only tools.
-
-* First GIT checkout
-
-You can get an anonymous copy of the source repository using any one
-of these three methods, although the CVS mirror is less tested:
-
-  $ git clone git://git.sv.gnu.org/autoconf
-  $ git clone http://git.sv.gnu.org/r/autoconf.git
-  $ cvs -d:pserver:[email protected]:/srv/git/autoconf.git \
-      co -d autoconf HEAD
-
-If you have a Savannah user name and commit rights to the Autoconf
-project, you should use this instead:
-
-  $ git clone <username>@git.sv.gnu.org:/srv/git/autoconf.git
-
-The next step is to generate files like configure and Makefile.in:
-
-  $ cd autoconf
-  $ autoreconf -vi
-
-Since we're building autoconf itself, and its tests are picky, the
-following procedure includes an extra step to ensure that some
-generated files are regenerated using the tools just built by "make"
-(if you use GNU make, the file GNUmakefile sets PATH for you):
-
-  $ ./configure
-  $ make
-  $ ( PATH=`pwd`/tests:$PATH; autoreconf -vi )
-  $ make check
-
-At this point, there should be no difference between your local copy,
-and the GIT master copy:
-
-  $ git diff
-
-should output no difference.
-
-The testsuite is run by 'make check'.  You may find it useful to run a
-subset of the testsuite; for example, all tests with the 'm4sugar'
-keyword as well as test 10:
-
-  $ make check TESTSUITEFLAGS='10 -k m4sugar'
-
-You can pass options to configure scripts invoked by the testsuite by
-setting the configure_options variable:
-
-  $ make check TESTSUITEFLAGS='configure_options="CC=gcc-2.95"'
-
-* Submitting patches
-
-All patches should be submitted to <[email protected]> for
-review, in context or unified diff format against the latest sources.
-In most cases, a patch should include a test case, to ensure that
-regressions do not creep back in.  Remember to add documentation and a
-NEWS entry for anything that is visible to the user.
-
-If your change is significant (i.e., if it adds more than ~10 lines),
-then you'll have to have a copyright assignment on file with the FSF.
-Since that involves first an email exchange between you and the FSF,
-and then the exchange (FSF to you, then back) of an actual sheet of paper
-with your signature on it, and finally, some administrative processing
-in Boston, the process can take a few weeks.
-
-The forms to choose from are in gnulib's doc/Copyright/ directory.
-If you want to assign a single change, you should use the file,
-doc/Copyright/request-assign.changes:
-
-    http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.changes;hb=HEAD
-
-If you would like to assign past and future autoconf work,
-you'd use doc/Copyright/request-assign.future:
-
-    http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD
-
-Enjoy!
-
------
-
-Copyright (C) 2002-2016 Free Software Foundation, Inc.
-
-Copying and distribution of this file, with or without modification,
-are permitted in any medium without royalty provided the copyright
-notice and this notice are preserved.  This file is offered as-is,
-without warranty of any kind.
-- 
2.9.3