Re: commit 9d0f14

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

On Thursday, 22 March 2018 10:26:33 Mojca Miklavec wrote:
> On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> >
> > another try at timestamp.h, this time using build date
> >
> > The Makefile rule for timestamp.h was broken when we switched from
> > cvs to git, since it relied on ChangeLog always being current.
> > Proposed replacement rules have so far failed to work for out-of-tree
> > builds or builds from a snapshot rather than a full git clone.
> > This attempt simply uses the current build date, which admittedly may
> > not be newer than the last-modified date but at least has the virtue
> > of not depending on git.
> 
> I just wanted to warn you that you will almost definitely get a
> request from Debian (as soon as you release the version that will
> behave this way and they try to package it) to stop doing that in the
> name of reproducible builds.

Release versions of gnuplot have the release date in this slot.
The timestamp is only used when you build the development version
directly from source.
 
>     https://reproducible-builds.org
> 
> My suggestion would be to:
> (a) Check if you are building from git and if so, run "git describe"
> to determine the version. That's probably by far the best way to
> determine the version.

If you build from a snapshot then git has no handle on the source
and cannot tell you anything about it.  So testing for git itself
does not help.

Even if you build from a working git clone, the previous makefile
recipes to invoke git failed for out-of-tree builds because the
directory structure during the build does not match that in the
git config file.  It was really annoying to me that "make distcheck"
would always fail for this reason.  This may be fixable, but the
fix would have to come from someone more clever than me.  
Checking the date was the best I could come up with.

> (b) When not building from git, you would usually build from a
> released tarball which should necessarily have the version written
> somewhere anyway and then you know which version that is exactly.

Building from a release tarball continues to work as it always has.


> Of course there are exceptions, like if someone deletes .git or
> fetches the zip from the download link from SF or GitHub or wherever,
> but you cannot solve all problems and the build date is totally
> useless in itself. I can probably build gnuplot 1.0 today and that
> won't tell you anything about the exact version I have in case I
> submit a bug report.

If you build any previous version, even a patchlevel release,
you get the release date.

I'd be happy to use a different Makefile rule if it covers
all the cases people are using.  The previous two attempts worked
some of the time but triggered bug reports from people using a
snapshot or building out of tree.

This whole approach is less satisfactory than the old (CVS) mechanism
of checking the top of the ChangeLog file.  What I really want, I think,
is an option attached to the "git commit" command that automatically
modifies the timestamp file to match the commit date.   The file itself,
not the metadata.  Something that persists outside of the git context. 
 

	Ethan