|
From: Daniel J S. <dan...@ie...> - 2013-08-06 20:33:37
|
On 08/06/2013 03:01 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.
This is sort of the assumption I made and hence the confusion. Maybe it
would be better to not do the "mv" step of:
sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-08-06 "/' \
version.c > version.ct;
mv version.ct version.c
and just compile the derivative file. If that were the case, then my
build outside the source tree would have failed because version.ct would
not appear. I suppose the intent here is to allow building to proceed
if the user doesn't have "sed" on their system, for example.
Are you building outside of the source tree? Perhaps we are running
into the same issue.
Dan
|