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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
