Re: Automatically keeping "last modified" up to date

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

On Tuesday, August 06, 2013 01:01:07 pm Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
> 
> > On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
> >> There's one other fishy thing in that neighborhood. When I do
> >> a cvs update it seems I quite often get the cvs 'M' flag
> >> indicating that src/version.c is modified, when I certainly
> >> haven't edited that file.
> >> Allin Cottrell
> >
> > Exactly.  That's as expected.
> > When you run "make" it changes gnuplot_date[] in version.c file to reflect
> > the most recently modified date.  So if you later update from CVS it sees
> > that your local copy of version.c is different from the base copy in CVS.
> 
> OK, I see. And I don't think this is a big deal. But isn't it 
> sort of a principle of version control to operate a strict 
> separation between files that are supplied from the repository 
> (and hence are, in a sense, "read-only") and files that are 
> automatically generated in the course of a build? Gnuplot's 
> version.c seems to cross that line.
> 
> Allin Cottrell

Well, that obviously doesn't make sense if your purpose in downloading
from CVS is to work on development.  The files are clearly not read-only.
You are editing and re-editing them constantly during the course of an
edit/build/debug cycle.  

The Makefile in the released version doesn't do this modification;
the date in version.c is fixed at the release date.  That's the idea behind
having a separate Makefile.maint that is only invoked during development,
not during a build from the packaged release.

So far as I know, this and most of the rest of the autotools-based
build procedure were put together years ago by Lars Hecking.
I try not to touch them if possible :-)

FWIW, my work flow is such that I never build on top of the directory
that CVS downloads into.   I have a script that builds via the sequence
1) create a new working directory
2) copy the CVS download into this new directory
3) cd to that directory
4) ./prepare
5) ./configure
6) make

When doing development I only modify and rebuild from files in this
working directory, so the issue of divergence from the pure CVS copy
does not arise.  To prepare a patch corresponding to the work I have
just done, I can do a "diff -urp" between the pristine CVS directory
and the working directory.  I realize that other people have other
work flows.

Anyhow, if I were designing the mechanism for tracking modification
date from scratch I would do it differently - probably by making the
modification date a defined constant and placing the definition in
the compilation command used by the Makefile.  If someone wants to
send a patch that does this (or something equivalent) I'd be happy
to try it out.

	Ethan