gnuplot-beta

more timestamp problems

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

Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
is currently not working if you start with a git snapshot downloaded
from SourceForge.   That's because the snapshot is a *.zip file that
doesn't include the git metadata, so the attempt to create
timestamp.h by querying git cannot work.

I wonder if we have control over the script on sf.net that creates
a snapshot?   Maybe that script could generate timestamp.h on the fly?

Another possibility is to assume that anyone downloading a snapshot
will unpack it immediately, in which case the timestamp can be the
creation date of the top level source directory.

	other ideas?

		Ethan

Re: more timestamp problems

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

sfeam via gnuplot-beta <gnu...@li...> writes:

> Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
> is currently not working if you start with a git snapshot downloaded
> from SourceForge.   That's because the snapshot is a *.zip file that
> doesn't include the git metadata, so the attempt to create
> timestamp.h by querying git cannot work.
>
> I wonder if we have control over the script on sf.net that creates
> a snapshot?   Maybe that script could generate timestamp.h on the fly?
>
> Another possibility is to assume that anyone downloading a snapshot
> will unpack it immediately, in which case the timestamp can be the
> creation date of the top level source directory.

I want to say we're doing something we shouldn't be doing, but I can't
quite figure out what's happening. The bug report is here:
https://sourceforge.net/p/gnuplot/bugs/2016/

The reporter says he sees this barf:

  cut: ../.git/HEAD: No such file or directory
  make: *** No rule to make target ../.git/', needed bytimestamp.h'. Stop.

The timestamp.h rule I see is this:

  timestamp.h: $(top_srcdir)/ChangeLog Makefile
          @echo Making $@
          @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
          @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
          @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
          @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
          @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

What is invoking cut and touching git? I don't see it.

Re: more timestamp problems

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

Oh, and building gitless snapshots is what all the distros do, so they
either already crossed this hurdle, or they haven't yet hit it. I don't
see any obvious patches in Debian, but I don't understand the problem
either, so maybe I'm not looking at the right thing.

Re: more timestamp problems

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

On Monday, 29 January 2018 21:46:20 Dima Kogan wrote:
> sfeam via gnuplot-beta <gnu...@li...> writes:
> 
> > Shige Takeno points out (Bug #2016) that ./prepare; ./configure; make
> > is currently not working if you start with a git snapshot downloaded
> > from SourceForge.   That's because the snapshot is a *.zip file that
> > doesn't include the git metadata, so the attempt to create
> > timestamp.h by querying git cannot work.
> >
> > I wonder if we have control over the script on sf.net that creates
> > a snapshot?   Maybe that script could generate timestamp.h on the fly?
> >
> > Another possibility is to assume that anyone downloading a snapshot
> > will unpack it immediately, in which case the timestamp can be the
> > creation date of the top level source directory.
> 
> I want to say we're doing something we shouldn't be doing, but I can't
> quite figure out what's happening. The bug report is here:
> https://sourceforge.net/p/gnuplot/bugs/2016/
> 
> The reporter says he sees this barf:
> 
>   cut: ../.git/HEAD: No such file or directory
>   make: *** No rule to make target ../.git/', needed bytimestamp.h'. Stop.
> 
> The timestamp.h rule I see is this:
> 
>   timestamp.h: $(top_srcdir)/ChangeLog Makefile
>           @echo Making $@
>           @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
>           @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
>           @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
>           @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
>           @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi

I get the same failure here.
But I see a different Makefile ruleset

BUILT_SOURCES = timestamp.h
git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD)
timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
        @echo Making $@
        @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
        @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
        @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
        @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
        @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
> 
> What is invoking cut and touching git? I don't see it.

Your Makefile seems to be from last year sometime.
We used to generate timestamp.h from ChangeLog, but git and ChangeLog do not
play nicely together so Bastian modified it to query the git metadata:

%%%%%%%%%%%%
commit dd0c5adaa6386470b207838b4296491bb0b15ac3
Author: Bastian Maerkisch <bma...@we...>
Date:   Tue Dec 26 11:10:52 2017 +0100

    Generate timestamp from last git commit date
    
    Generation of the timestamp relied on the latest date in the ChangeLog.
    This may no longer be correct.  Instead, we now query git for the last
    commit date.  Only works for development builds from a git checkout, but
    for release builds the date is hard-coded in src/version.c.
%%%%%%%%%%%%

Unfortunately the new mechanism covers building from git and building
from a release tarball but not building from an auto-generated snapshot.

	Ethan

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

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

Re: more timestamp problems

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

On Mon, 29 Jan 2018, sfeam via gnuplot-beta wrote:

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

I think you have to delete and recreate them.

Allin Cottrell

Re: more timestamp problems

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

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

> My interest in having a correct date is to increase the chance of
> getting complete information in a bug report.

That's definitely important, but the date is not the same as the
version, which is the thing you really want. How about we print the git
hash instead of the date? That's available in theory (in the directory
name you get from that archive).


> But I haven't had great luck in trying to create a Makefile rule that
> works.

I can write the Makefile rule, but these git-less archives lack the
necessary information. What would you like? If we can't/don't want to
get rid of those archives, how about we move to version strings, and
I'll give you a Makefile patch?