]> git.ipfire.org Git - thirdparty/autoconf.git/commitdiff
Mention more details about git usage in bootstrap.
authorEric Blake <ebb9@byu.net>
Tue, 15 Apr 2008 12:56:56 +0000 (06:56 -0600)
committerEric Blake <ebb9@byu.net>
Tue, 15 Apr 2008 12:56:56 +0000 (06:56 -0600)
Signed-off-by: Eric Blake <ebb9@byu.net>
README-hacking

index 0b8b0d93266f2220ec67aaa8d247a77b559bb859..f9b8873dce7f559a6bed24b45bebabba73c3d414 100644 (file)
@@ -11,7 +11,7 @@ maintainer-specific rules.
 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 the latest stable versions of the maintainer
+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/>
@@ -28,9 +28,24 @@ like "make dist-lzma" or "make distcheck":
 - 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
+
 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
@@ -82,9 +97,6 @@ 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.
 
-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
-
 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,