X-Git-Url: https://diplodocus.org/git/nmh/blobdiff_plain/20fe3a947f2305fb271a811d50f8a7d263511ee7..c0f27fe2e6f1e553818f6a43aad0e30cec7994b7:/docs/README.developers?ds=sidebyside diff --git a/docs/README.developers b/docs/README.developers index b2c2efa0..522244a1 100644 --- a/docs/README.developers +++ b/docs/README.developers @@ -41,12 +41,24 @@ 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: +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 timestamps on the +files change when the commits are done and the RCS Ids change. If one committed +all the files in one fell swoop (in the above relative order), timestamps would +cause unnecessary autoconf regeneration on 'make's after the commit, which would +waste your time and would cause your local stamp-h.in to be out-of-sync with the +one checked into CVS (not the end of the world, but...). + +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 +142,21 @@ zotnet/tws/ "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 -------------