-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
- % autoheader; autoconf; \date > stamp-h.in
- % cvs commit config.h.in configure stamp-h.in
-
-The reason for the three-step commit is that configure.in contains the RCS $Id
-keyword, so when you commit it, a new version is written locally. Therefore,
-the autoconf regeneration should be held off until after the commit, or your
-local stamp-h.in will become out-of-sync with the CVS version (granted, not that
-big a deal). For the second step, you're doing the same commands as a
-`make reset' would do, but using that command would require extra configure runs
-to make Makefile be up-to-date. The reason for the backslash on `date' is in
-case you have `date' aliased in your shell to use a nonstandard format.
-
-If you haven't changed all the files noted above, just commit the ones you have
-changed, in the stated order (for instance, configure.in, then configure and
-stamp-h.in).