BUILDING_FROM_VCS

[John Ralls]

> On Mar 12, 2018, at 10:32 AM, Eric Siegerman <pub08-gnc at davor.org> wrote:
> 
> On Sat, Mar 10, 2018 at 11:36:13PM +0100, Geert Janssens wrote:
>> Make dist is called all the time by developers to test the creation of a dist tarball, so the info would get updated more frequently then intended. Or it would require manual intervention,  which brings us back at square one. 
> 
> I think I was unclear.  What I was trying to say was that any changes to (or exclusions of) the sentinel file should occur *only* in the distribution tarball (or whatever); the file in the source tree shouldn't be modified by "make dist".[*]  (That might be non-trivial for an in-source-tree build, but you recommend against those anyway.)
> 
> [*] That's why the source-tree version shouldn't say "I'm from git commit 123abc", but should statically say merely "I'm from git".
> 
>> Unfortunately it does matter. Github allows you to download any commit as a tarball. That tarball would also include the sentinel...
> 
> This, however, does seem to be a showstopper for the idea :-(

Indeed.

The point is to generate a version number so that one can easily identify when one is running a release, a nightly, or for developers the version that one thinks one just built or the one from two commits ago because one forgot to run `ninja install`. My original proposal, to check that the fetch origin is one of our repositories, serves that purpose for GnuCash contributors... though your point that one might use one's own repository for "origin" and use a different one for the canonical one is well taken and solved by replacing the regex with "\(code\.gnucash\.org/\|github\.com.\)gnucash.*(fetch)" (untested, might need tweaking). 

That way even if you are using a clone-of-a-clone then simply adding the canonical repo as a remote will turn on setting the version to a commit date and shortened hash. We could even retrieve the "origin" url and stick it in the About dialog to help keep track of where a commit came from.

If someone is using a different VCS that's not really our problem, so it's incumbent on them to modify whatever cmake file this ends up in to stamp their work accordingly.

It's easy to get paranoid about someone redistributing modified code and passing it off as vanilla GnuCash but with the source readily available and modifiable there's nothing much we can do about it aside from code-signing the bundles.

As for ChangeLog, if we keep it we can just make the generation fail gracefully if "git log" errors out. Again, if someone is using a different VCS then it's up to them to modify the code to work with that VCS if they want a ChangeLog.

Regards,
John Ralls