Eric Siegerman pub08-gnc at
Sat Mar 10 14:34:39 EST 2018

On Sat, Mar 10, 2018 at 09:00:29AM -0800, John Ralls wrote:
> One possible solution would be to test the value of `git remote -v 2> /dev/null | grep "origin.*(fetch)"`. If it’s either code or the Github mirror then we set the version from `git describe`, otherwise it’s the ${VERSION} as set in CMakeLists.txt.

This seems fragile.  (1) If someone's building from a clone of a clone, it will fail.  (2) The remote might not be called "origin" (e.g. I typically use "upstream").

Here's an idea: add a sentinel file to the git repo, but exclude it from the dist tarballs etc.  If the file exists in the source tree, you're building from the official git repo or a (possibly indirect) clone of same.  If it doesn't exist, you're building from something else (and I don't think it matters what variety of something-else -- tarball, tarball-checked-into-git, etc.)  The sentinel's content is irrelevant (unless for extra certainty you want the git-repo check to verify it); it's the file's presence or absence that matters.

This has the advantage of being VCS-agnostic, since it only looks at the working tree.

Or the sentinel could always exist, but its contents could provide the needed info. E.g. it's in the source tree with (hard-coded and git-committed) contents that say basically "I'm from git".  But the dist build puts into the tarball a variant that says, "My ultimate source is {release 2.7.5|official git commit 123abc|<whatever else makes sense>}, but I'm not directly from there".  Not in those exact words, obviously.

What makes gnc-version.h and gnc-vcs-info.h unsuitable is that they're regenerated on a normal "make all" build, if necessary.  The key would be that the sentinel I'm suggesting is only generated at "make dist" time:
  - if you're building from an official repo (or clone), the file never changes
  - if you're building from a tarball, the file still never changes
It only changes at the transition between those two states, i.e. "make dist".

> ChangeLog is a bit harder [...] or maybe it should be simply dropped.

That would be unfortunate.  Even though the info is available elsewhere, it's good to have it encapsulated with the rest of the distribution.

  - Eric

More information about the gnucash-devel mailing list