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
