---------------
-autoconf files
---------------
-
-If you wish to change the `configure' script or its related files, you'll need
-to first install GNU m4, available from <ftp://ftp.gnu.org/pub/gnu/m4/> and then
-GNU autoconf (<ftp://ftp.gnu.org/pub/gnu/autoconf/>).
-
-Most of the configure-related files are automatically generated. The only files
-you should need to manually edit are acconfig.h and configure.in. Don't, for
-instance, edit config.h.in. Though it is an input file from the point of view
-of the users (and the configure script) it is an output file from the point of
-view of the developers (and the autoconf script).
-
-If you do change acconfig.h or configure.in and want to `cvs commit' them, be
-sure to regenerate the output files and commit them as well. The easiest way to
-regenerate the files is to simply run `make' -- it'll do the necessary calls of
-autoconf and autoheader and will do a `./config.status --recheck', which will
-exercise your new configure script.
-
-When you commit the configure-related files, it's very important to commit them
-in the right order. The timestamps on the files in the CVS archive are based on
-the current time at the moment they were committed -- the timestamps from the
-local files you commit are not copied over. If you commit the files in the
-wrong order, you'll cause unnecessary calls of `autoconf' to occur when people
-try to `make' their copies of the latest CVS source. These people may be
-end-users who don't have any interest in changing the configure-related files
-and don't have autoconf installed. They'll be unable to make without playing
-around with `touch'.
-
-The correct procedure to commit the configure-related files is:
-
- % cvs commit acconfig.h aclocal.m4 configure.in
- % autoconf && autoheader # or simply "make"
- % cvs commit config.h.in configure
- % make stamp-h.in # or simply "make"
- % cvs commit stamp-h.in
-
-The reason that the commits need to be split up is that the timestamps on the
-files change when the commits are done and the RCS Ids change. If one committed
-all the files in one fell swoop (in the above relative order), timestamps would
-cause unnecessary autoconf regeneration on 'make's after the commit, which would
-waste your time and would cause your local stamp-h.in to be out-of-sync with the
-one checked into CVS (not the end of the world, but...).
-
-If you haven't changed all the files noted above, just commit the ones you have,
-in the stated order (for instance, configure.in, then configure, then
-stamp-h.in).
+-------------------------
+autoconf & automake files
+-------------------------
+
+If you wish to change the `configure' script, the generated Makefile
+or other related files, you'll need to first install GNU m4, available
+from <ftp://ftp.gnu.org/pub/gnu/m4/>, then GNU autoconf
+(<ftp://ftp.gnu.org/pub/gnu/autoconf/>) and GNU automake
+(<ftp://ftp.gnu.org/pub/gnu/automake/>). Nmh is currently using a
+minimum of autoconf 2.61 and automake 1.10.
+
+Most of the configure-related files are automatically generated.
+The only files you should need to manually edit are configure.ac
+and any autoconf macros in the m4 directory. Don't, for instance,
+edit config.h.in. Though it is an input file from the point of
+view of the users (and the configure script) it is an output file
+from the point of view of the developers (and the autoconf script).
+
+If you wish to add a new autoconf macro, it should be placed in it's
+own file and put in the m4 directory; aclocal will automatically pick
+it up and automake will add it to the distribution target automatically.
+
+If you wish to make changes to the Makefile, you will need to edit
+Makefile.am. See the automake documentation if you need further help.
+You should always check changes to Makefile.am by using "make distcheck".
+
+Note that the automatically generated autotools files (such as config.h.in,
+Makefile.in, and configure), are NOT kept in git. Thus, when you check out
+a git tree, you need to run the autogen.sh script before you can build
+anything:
+
+ % ./autogen.sh