X-Git-Url: http://git.marmaro.de/?a=blobdiff_plain;f=docs%2FREADME.developers;h=74c3c07503d49cc1addf6c48d867af08ba4cc982;hb=93b9385f594f86b215fb786953b792473234b59d;hp=f93c70bd72a4afe7eb969031bc02ea68eee0b90a;hpb=2ef1a2bc54aa523b9edbb830959f17a3ed05d74d;p=mmh diff --git a/docs/README.developers b/docs/README.developers index f93c70b..74c3c07 100644 --- a/docs/README.developers +++ b/docs/README.developers @@ -44,19 +44,19 @@ around with `touch'. The correct procedure to commit the configure-related files is: % 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 - -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 ] 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 + % autoheader; autoconf; date > stamp-h.in + % cvs commit config.h.in configure stamp-h.in + +The reason for the three-step commit is that configure.in contains the RCS $Id +keyword, so when you commit it, a new version is written locally. Therefore, +the autoconf regeneration should be held off until after the commit, or your +local stamp-h.in will become out-of-sync with the CVS version (granted, not that +big a deal). For the second step, you're doing the same commands as a +`make reset' would do, but using that command would require extra configure runs +to make Makefile be up-to-date. + +If you haven't changed all the files noted above, just commit the ones you have +changed, in the stated order (for instance, configure.in, then configure and stamp-h.in). @@ -137,8 +137,11 @@ zotnet/mts/ MTS code not specific to any single MTS apparently goes here. zotnet/tws/ - No idea what "tws" stands for, other than 't' almost certainly standing for - "time". Date and time manipulation routines go here. + "tws" apparently stands for "time with structure", a rather odd phrase. + This directory used to be the place for date and time manipulation code, but + currently nothing in here is compiled. There are new, more portable + versions of the key files in h/ and sbr/, and this directory will soon go + away completely. -------------------------------------------------------