Re: Automatically keeping "last modified" up to date

[Ethan A M. <sf...@us...>]

On Tuesday, August 06, 2013 12:25:08 pm Daniel J Sebald wrote:
> On 08/06/2013 01:39 PM, Ethan Merritt wrote:
> > On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
> >> I just built the most recent version of gnuplot and noticed that the
> >> "last modified" date in the intro refers back to 2012 and is manually
> >> entered.  Why can't that automatically be generated?  It would be nice
> >> to do this so that when one builds/installs the latest version, upon
> >> launching the program it is immediate clear that the install process was
> >> successful by looking at the "last modified" date.
> >>
> >> Here are some approaches that could be tried:
> >>
> >> 1) There is this configure.in file containing:
> >>
> >> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
> >>
> >> Is that file somehow generated by the CVS/repository to reflect the most
> >> recent modification of the repository?  If so, that would be great as it
> >> would also contain a time stamp.  Could write a script to search for
> >> that and define LAST_MODIFIED in some header file using the extracted
> >> "2013/07/18 23:22:17" string.
> >>
> >> 2) Is there some way during make to get the most recent date of all the
> >> pertinent files?  "make" does date checking, so perhaps there is a make
> >> variable/macro that reflects that.
> >>
> >> 3) Similar to #2, we could maybe write an OS script that does the same
> >> thing by looking for the date of the most recent file in the source tree.
> >>
> >> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for
> >> the most recent date near the top of the file and use that as a
> >> definition for LAST_MODIFIED.
> >
> > The file .../src/Makefile.maint exists for exactly this purpose.
> > It updates the version string based on the most recent date in ChangeLog.
> > This file is included during "make" by gnu make.
> > Possibly you are using some other make program?
> >
> > 	Ethan
> 
> Well, I see the file Makefile.maint, but I'm not sure what I'm looking 
> at.  I see some THIS_VERSION, PREV_VERSION , etc. but I don't know how 
> that ties into what I see in the source code.  In show.c is the line:
> 
>      fprintf(fp, fmt,
> 	    p,			/* empty line */
> 	    p, PROGRAM,
> 	    p, gnuplot_version, gnuplot_patchlevel, gnuplot_date,
> 
> in which gnuplot_date is the "last modified" date.  And that variable 
> comes from version.c, i.e.,
> 
> const char gnuplot_date[] = "2012-06-19 ";
> 
> but I can't find anything in a make file that indicates gnuplot_date[] 
> is automatically generated.  One has to manually change that, correct?

No. 
It is automatically updated during "make".
I've never had any problem with this, so I don't know what might be going
wrong on your machine.

Here's what I see:

chauvet [92] make version.o
Making version.c
sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-07-25 "/' \
            version.c > version.ct;
mv version.ct version.c
gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include -I/usr/local/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -g -O2 -MT version.o -MD -MP -MF .deps/version.Tpo -c -o version.o version.c
mv -f .deps/version.Tpo .deps/version.Po

 
> I do see at the top of the file version.c:
> 
> #ifndef lint
> static char *RCSid() { return RCSid("$Id: version.c,v 1.107 2013/02/26 
> 23:38:42 sfeam Exp $"); }
> #endif
> 
> which looks like it has something to do with revision control system, 
> but perhaps on a single file basis.  We would want something on a 
> project-wide basis.  Is that what configure.in is?

No. That is something else entirely, not relevant to the current issue.