-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
- % cvs commit config.h.in configure
- % make stamp-h.in
- % cvs commit stamp-h.in
-
-If you haven't changed all of those files, just commit the rest in the stated
-order (e.g. cvs commit acconfig.h config.h.in stamp-h.in). The reason for
-the sequence is the RCS Id strings in the edited files -- they change when
-you commit the changes.
-
-You can run just "make" instead of the other commands in between cvs commits.
+Note that the automatically generated autoconf files (such as config.h.in,
+stamp-h.in, and configure), are NOT kept in CVS. Thus, when you check out
+a CVS tree, you need to do the following things before you can build
+anything: