Re: [PATCH] Support building development version without git

Ethan A Merritt <[email protected]>
Newsgroups gmane.comp.graphics.gnuplot.devel
Organization University of Washington
Message-ID <2538441.uNY6CgVRDI@stonelion>
On Wednesday, 1 July 2020 15:35:03 PDT Henri Menke wrote:
> On 01/07/20, 03:30, Dima Kogan wrote:
> > Henri Menke <[email protected]> writes:
> > 
> > > If I go to the SourceForge project page [1] and just hit the `Download
> > > Snapshot' button in the upper right corner, I get a zip file with all
> > > the source but no .git folder and also no timestamp.h. I suspect there
> > > is no or at least no easy way to make SourceForge preprocess the
> > > source when generating a snapshot.
> > >
> > > Within the Makefile determining the latest change would be tricky. The
> > > only way I can think of right now would be to run stat on all the
> > > files in the source tree and pick the newest one, but that is slow and
> > > ugly. Maybe instead of using the current date if git is unavailable
> > > just do echo '0000-00-00'. It should be pretty obvious that this is
> > > not the true `Last modified' then.
> > 
> > Oh. Wow. OK. My feeling is that people should be either
> > 
> > - using release tarballs
> > - using git
> > 
> > It's unfortunate that sourceforge makes another option available without
> > asking, but I don't think it's worth the effort to support it, and a
> > dummy string is just fine. Is a date string of "DATE UNKNOWN; PLEASE USE
> > A RELEASE TARBALL OR A GIT CHECKOUT" valid for the purposes of
> > timestamp.h? Ethan: do you want to support this use case in a better
> > way?
> 
> The original motivation for this change was that I wanted to build the
> development version on NixOS.  In the Nix packaging system you can build
> stuff directly from a git checkout, but because the system emphasizes
> reproducible builds, the build cannot depend on the contents of the .git
> directory because these are actually non-deterministic (due to git gc),
> so two checkouts of the same commit may actually have a different .git
> directory.  This will lead to spurious build failures because the output
> hashes differ.
> 
>     https://github.com/NixOS/nixpkgs/issues/8567
>     https://github.com/NixOS/nixpkgs/issues/20521
> 
> I thought it would be a good idea to upstream the support for this but
> if this is too much of a pain here, I can also patch it locally.
> 
> Kind regards,
> Henri

Let me add a 3rd reason why it would be a good idea to re-think the
current timestamp dependency:   
If you use "git bisect"  for debugging, it is made more cumbersome by the
fact the builds fail because the timestamp dependency in the Makefile is
not satisfied by the content of the git repository as seen during the
bisection.   

Henri:

Unfortunately your patch doesn't work for me. 

When I apply the patch and run
  ./prepare
  ./configure
  make

I end up with an executable that reports it's version as 

        G N U P L O T
        Version 5.5 patchlevel 0    last modified %cs

Was your change from "--format=%ci" to "--format=%cs" intentional,
or was it just a typo? 
  git --version
  git version 2.21.3
  git log -1 --format=%cs
  %cs
  git log -1 --format="%cs"
  %cs


If I change it back to %ci I get 

        G N U P L O T
        Version 5.5 patchlevel 0    last modified 2020-06-30 20:23:26 -0700

which is correct but obviously longer than just the date.

	Ethan









_______________________________________________
gnuplot-beta mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.