-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 order to commit the configure-related files is:
-
-% cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure 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).
+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 run the autogen.sh script before you can build
+anything: