Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

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.

> 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 :-)

I agree that not monkeying with standard autotools procedures 
is good policy. My point is just this: I build several pieces 
of autotooled software from VC, and gnuplot is the only case 
where a straight build, with no editing, leaves me with a file 
in the source tree that is marked as "modified" relative to 
the repository.

Allin Cottrell