Re: more timestamp problems

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> Your Makefile seems to be from last year sometime.

Oh yeah. My git remote was still pointing to Mojca's unofficial mirror.
After some poking around, I found the new git repo, but it was hard to
find. Can we (whoever has the access) please put a git link here:

  http://www.gnuplot.info/download.html

And also the main sf page: https://sourceforge.net/projects/gnuplot/ has
a nav-bar where "Code" goes to CVS and "gnuplot-main" goes to git. Can
whoever please make ths more sensible?


OK, as for the issue at hand, what we're doing is this: (yes?)

  - We're generating a 'gnuplot_date' string to be printed out when the
    user runs 'gnuplot'

  - If we're building from version control, we want to take the date of
    the most recent commit

  - If we're building a release, DEVELOPMENT_VERSION will not be
    defined, and we'll use the hard-coded string in version.c

  - If we somehow have a tarball that is NOT a release, then we have a
    problem

I don't see any way to do this "properly", but I argue that non-release
non-version-controlled tarballs are a bad idea, and we shouldn't be
making them available (is turning that off an option?) If you
care-enough to grab the bleeding edge you should be using version
control.

Or if we really want to make this code path work, I think your idea of
simply using the current date is perfectly reasonable. At worst, we'll
print a slightly wrong thing in the startup screen, which will then be
ignored by the user anyway.

Sorry I have no magic insight, but this isn't a battle worth fighting, I
think.

dima