Make AS_IF, AS_CASE, and AS_FOR more robust to blank arguments.
[autoconf.git] / README-hacking
blob5d84404696fd4867fc57f61f2bbc252fe63c77f1
1 -*- outline -*-
3 These notes intend to help people working on the checked-out sources.
4 These requirements do not apply when building from a distribution
5 tarball.  Don't put this file into the distribution.  Don't mention it
6 in the ChangeLog.  You may want to also see HACKING for
7 maintainer-specific rules.
9 * Requirements
11 We've opted to keep only the highest-level sources in the GIT repository.
12 This eases our maintenance burden, (fewer merges etc.), but imposes more
13 requirements on anyone wishing to build from the just-checked-out sources.
14 For example, you have to use recent stable versions of the maintainer
15 tools we depend upon, including:
17 - Autoconf 2.60+ <http://www.gnu.org/software/autoconf/>
18 - Automake 1.10+ <http://www.gnu.org/software/automake/>
19 - Help2man 1.29+ <http://www.gnu.org/software/help2man/>
20 - M4 1.4.5+ <http://www.gnu.org/software/m4/>
21 - Perl 5.005_03+ <http://www.cpan.org/>
22 - Texinfo 4.8+ <http://www.gnu.org/software/texinfo/>
24 The following are useful as well, if you want to be able to run commands
25 like "make dist-lzma" or "make distcheck":
27 - Gzip <http://www.gnu.org/software/gzip/>
28 - Tar <http://www.gnu.org/software/tar/>
29 - LZMA Utils 4.32+ <http://tukaani.org/lzma/>
31 Although we try to keep the CVS mirror of the git repository usable,
32 some of the tests in the testsuite will fail if git was not used to
33 generate the version string.  Therefore, we recommend:
35 - Git 1.4.4+ <http://git.or.cz/>
37 You may find it useful to install the git-merge-changelog merge driver:
38 http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
40 then add the following to .git/config or ~/.gitconfig:
41 [merge "merge-changelog"]
42         name = GNU ChangeLog merge driver
43         driver = git-merge-changelog %O %A %B
44 [diff "texinfo"]
45         funcname = ^@node[\t ][\t ]*\\([^,][^,]*\\)
47 Only building the initial full source tree will be a bit painful.
48 Later, a plain `git pull && make' should be sufficient.
50 If you want to test Autoconf on a machine without git, it may be
51 easier to first bootstrap Autoconf on a different machine with git,
52 run `make dist', and copy the tarball to the machine under test.  It
53 should always be possible to create a self-contained tarball which
54 does not rely on the bootstrap-only tools.
56 * First GIT checkout
58 You can get an anonymous copy of the source repository using any one
59 of these three methods, although the CVS mirror is less tested:
61   $ git clone git://git.sv.gnu.org/autoconf
62   $ git clone http://git.sv.gnu.org/r/autoconf.git
63   $ cvs -d:pserver:anonymous@pserver.git.sv.gnu.org:/srv/git/autoconf.git \
64       co -d autoconf HEAD
66 If you have a Savannah user name and commit rights to the Autoconf
67 project, you should use this instead:
69   $ git clone <username>@git.sv.gnu.org:/srv/git/autoconf.git
71 The next step is to generate files like configure and Makefile.in:
73   $ cd autoconf
74   $ autoreconf -vi
76 Since we're building autoconf itself, and its tests are picky, the
77 following procedure includes an extra step to ensure that some
78 generated files are regenerated using the tools just build by "make"
79 (if you use GNU make, the file GNUmakefile sets PATH for you):
81   $ ./configure
82   $ make
83   $ ( PATH=`pwd`/tests:$PATH; autoreconf -vi )
84   $ make check
86 At this point, there should be no difference between your local copy,
87 and the GIT master copy:
89   $ git diff
91 should output no difference.
93 The testsuite is run by 'make check'.  You may find it useful to run a
94 subset of the testsuite; for example, all tests with the 'm4sugar'
95 keyword as well as test 10:
97   $ make check TESTSUITEFLAGS='10 -k m4sugar'
99 * Submitting patches
101 All patches should be submitted to <autoconf-patches@gnu.org> for
102 review, in context or unified diff format against the latest sources.
103 In most cases, a patch should include a test case, to ensure that
104 regressions do not creep back in.  Remember to add documentation and a
105 NEWS entry for anything that is visible to the user.
107 If your change is significant (i.e., if it adds more than ~10 lines),
108 then you'll have to have a copyright assignment on file with the FSF.
109 Since that involves first an email exchange between you and the FSF,
110 and then the exchange (FSF to you, then back) of an actual sheet of paper
111 with your signature on it, and finally, some administrative processing
112 in Boston, the process can take a few weeks.
114 The forms to choose from are in gnulib's doc/Copyright/ directory.
115 If you want to assign a single change, you should use the file,
116 doc/Copyright/request-assign.changes:
118     http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.changes;hb=HEAD
120 If you would like to assign past and future autoconf work,
121 you'd use doc/Copyright/request-assign.future:
123     http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD
125 Enjoy!
127 -----
129 Copyright (C) 2002-2008 Free Software Foundation, Inc.
131 This program is free software: you can redistribute it and/or modify
132 it under the terms of the GNU General Public License as published by
133 the Free Software Foundation, either version 3 of the License, or
134 (at your option) any later version.
136 This program is distributed in the hope that it will be useful,
137 but WITHOUT ANY WARRANTY; without even the implied warranty of
138 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
139 GNU General Public License for more details.
141 You should have received a copy of the GNU General Public License
142 along with this program.  If not, see <http://www.gnu.org/licenses/>.