mirror/autoconf
2
0
Fork 0
mirror of git://git.sv.gnu.org/autoconf synced 2025-04-06 15:10:23 +08:00
Code Issues Packages Projects Releases Wiki Activity

Mention more details about git usage in bootstrap.

Browse Source 
Signed-off-by: Eric Blake <ebb9@byu.net>
This commit is contained in:
Eric Blake 2008-04-15 06:56:56 -06:00
parent c1cd13960d
commit c48d3a706f
1 changed files with 16 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
README-hacking
View 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,