Clarified and made some corrections to Kimmo's README.developers changes (BTW,

[nmh] / docs / README.developers

diff --git a/docs/README.developers b/docs/README.developers
index b2c2efa..f93c70b 100644 (file)
--- a/docs/README.developers
+++ b/docs/README.developers
@@ -41,12 +41,23 @@ 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'.
 
 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:
+The correct procedure to commit the configure-related files is:

 
 

-% cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in
+    % 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

 
 

-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 that the commits need to be split up is that the RCS Id strings
+in the files change when you commit, which can apparently mess up the
+dependencies.  [How?  -- Dan Harkless <dan-nmh@dilvish.speed.net>]  If this were
+not the case, you could commit with a single make followed by a
+cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in.
+
+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).

 
 
 -------------------
 
 
 -------------------


@@ -130,6 +141,21 @@ zotnet/tws/
     "time".  Date and time manipulation routines go here.
 
 
     "time".  Date and time manipulation routines go here.
 
 

+-------------------------------------------------------
+nmh-local functions to use in preference to OS versions
+-------------------------------------------------------
+
+For some system functions whose availability or behavior varies from OS to OS,
+nmh conditionally uses a local definition with the same name as the OS function
+(e.g. snprintf()).  For other functions, developers need to avoid the OS
+versions and always use the nmh-supplied function.  Here is a list of such
+functions: 
+
+OS function  nmh-local version to use instead
+===========  ================================
+getpass()    nmh_getpass()
+
+

 -------------
 releasing nmh
 -------------
 -------------
 releasing nmh
 -------------