|
From: Allin C. <cot...@wf...> - 2013-08-06 20:48:55
|
On Tue, 6 Aug 2013, Daniel J Sebald wrote: > 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. I build gnuplot in its own source tree, so that's not the issue for me. I just tried a CVS update and build, and this time it worked fine, showing the current date. Maybe something extraneous caused a problem before, but it seems to me there's a certain brittleness here. Allin Cottrell |