* If the module needs configure-time checks, write an autoconf
macro for it in m4/<module>.m4. See m4/README for details.
* Write a module description modules/<module>, based on modules/TEMPLATE.
+* If the module contributes a section to the end-user documentation,
+ put this documentation in doc/<module>.texi and add it to the "Files"
+ section of modules/<module>. Most modules don't do this; they have only
+ documentation for the programmer (= gnulib user). Such documentation
+ usually goes into the lib/ source files. It may also go into doc/;
+ but don't add it to the module description in this case.
* Add the module to the list in MODULES.html.sh.
You can test that a module builds correctly with:
following should work:
$ cvs -d :pserver:anoncvs@cvs.gnu.org:/cvsroot/gnulib login
-(Just hit Enter or Return when prompt for a password)
+(Just hit Enter or Return when prompted for a password)
$ cvs -d :pserver:anoncvs@cvs.gnu.org:/cvsroot/gnulib checkout gnulib
Gnulib is hosted on savannah.gnu.org. The project page is
http://savannah.gnu.org/projects/gnulib.
+Keeping Up-to-date
+==================
+
+The best way to work with Gnulib is to check it out of CVS.
+Subscribing to the bug-gnulib@gnu.org mailing list will help you to
+plan when to update your local copy of Gnulib (which you use to
+maintain your software) from CVS. You can use "cvs update -dP" to
+synchronize.
+
+Sometimes, using an updated version of Gnulib will require you to use
+newer versions of GNU Automake or Autoconf. You may find it helpful
+to join the autotools-announce mailing list to be advised of such
+changes.
+
-----
Copyright (C) 2001, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.