Re: Automatically keeping "last modified" up to date

[Juhász P. <pet...@gm...>]

On Wed, 2013-08-07 at 09:42 +0100, Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
> 
> > 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.
> 
> That's why I said "in a sense, read-only": the "sense" was 
> supposed to be that they are in effect read-only if you're 
> just building gnuplot from CVS. You don't want to modify 
> anything inadvertently. If you're hacking on the code, 
> obviously you're free to modify any file.
> 

My 2 cents:

The technical issue we have here is rooted in a deeper matter of
principle. In any source repository there may be source files that are
"static" in the sense that they are not changed during the make process
and fed to the compiler as is, and template files, which are not
compiled directly, but some process generates the required source files
from them. Version.c, as we have it now, tries to be both: there is a
magical process in place that modifies it with the current date, but it
happens to be compilable without modification (likely because someone
have checked in a processed version to the repository earlier).

There ought to be a separation between the two kinds of files, one that
is clearly reflected in the naming convention.
So the one and only file in the repository should be a template file,
called version.c.templ or something, and the magical update process
should create from it the source file version.c, which should not be
under version control. This magical process would substitute the current
date into the file, as it does now, but, in extreme cases where there is
no sed available etc., it could fall back to simply copying the contents
of the file (which means that the default contents should be sensible
and compilable).

Peter Juhasz