Re: more timestamp problems

[sfeam <sf...@us...>]

On Monday, 29 January 2018 22:42:21 Dima Kogan wrote:
> 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

OK, although as you point out below it wouldn't be necessary if the
tabs on the main page toolbar had better labels.

> 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?

I wish.
There is no obvious way to name/rename those tabs.
The "edit" function only allows you to move them around or delete them
altogether. I've never seen any documentation for the SourceForge interface.

> 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.

Not sure I agree with that.  Unless you are already familiar with 
git (or Hg or svn or ...) that's an unnecessary extra hurdle.
 
> 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.

My interest in having a correct date is to increase the chance of getting
complete information in a bug report. But I haven't had great luck in
trying to create a Makefile rule that works.

	Ethan