[GNC-dev] Significance of 18:59:00 in GnuCash 2.6.21 and altering of existing data

[Geert Janssens]

Op maandag 4 mei 2020 12:30:28 CEST schreef Kevin Buckley:
> Wonder if I could ask a couple of related questions about 2.6.21,
> before letting you get back to working on the current version.
> 
> Because of your suggestion that there might be some back-portable
> changes, I checked out a local copy of the Gnucash Git repo's
> default branch "maint" and then reverted to the state at the
> 2621a tag, or
> 
> commit 868489b1c4f9b1f64fe61130e6ae28b4bad16f22
> Author: John Ralls <jralls at ceridwen.us>
> Date:   Tue Apr 10 09:52:02 2018 -0700
> 
>     Fix typo.
> 
> 
> so as to start from what appeared to be the last identifiable
> commit for the 2.6 series.
> 
> In coming to use that commit though, I found a couple of inconsistencies.
> 
> I did the following
> 
> ./autogen.sh
> ./configure --various-options
> make dist-bzip2
> 
> and that generated a gnucash-2.6.21.tar.bz2 file. So far, so good.
> 
> In looking to compare the contents of my tarball, with the
> official gnucash-2.6.21.tar.bz2 file, however, I've noticed
> a few differences.
> 
> Some I can explain away as products of my autotools versions
> being different but others, such as this one,
> 
> $ diff GIT/gnucash-2.6.21/src/core-utils/gnc-vcs-info.h \
>            gnucash-2.6.21/src/core-utils/gnc-vcs-info.h
> 2c2
> < #define GNUCASH_SCM_REV "868489b+"
> ---
> 
> > #define GNUCASH_SCM_REV "868489b1c+"
> 
> $
> 
> where the Git hash is the same, but differs in length, are
> harder to account for.
> 
> That hash, as I'm sure you will know, comes from running
> 
>   util/gnc-vcs-info -r .
> 
> inside a Git working directory which, in turn is doing a
> pretty (no pun intended) bog standard
> 
>    git log -1 --pretty=format:"%h" HEAD
> 
> and then adding the plus (+) if any files in the repo are
> seen to have been altered.
> 
> Clearly, files get altered as part of making a dist-zip2
> target because my source dir was prstine.
> 
> Do different Git-s have different short hash lengths ?
> 
No, but git decides on the short hash length itself. IIUC it depends on the number of objects in 
the repo and the likelyhood of short hash overlap.


> 
> The second case is wierder still, in that I notice, for
> example.
> 
> 
> $ diff GIT/gnucash-2.6.21/src/gnc-module/swig-gnc-module.c \
>            gnucash-2.6.21/src/gnc-module/swig-gnc-module.c
> 
> ... stuff above ...
> 1496,1497c1503,1504
> <         found=1;
> <         break;
> ---
> 
> >         /* Our module is already in the list, so there's nothing more to
> >         do. */
> >         return;
> 
> 1502,1504c1509
> <     /* if the is found in the list, then all is done and we may leave */
> <     if (found) return;
> <     /* otherwise we must add out module into the list */
> ---
> 
> >     /* otherwise we must add our module into the list */
> 
> Initially, given the swig in the file name, I had almost allowed for the
> differences as resulting from different swig versions but, on closer
> inspection, noted the different text, including the fixing up of the
> ".. add out module ..." text, to the correct "... add our module ..."
> 
> Howver, I can't find that change in the repo, as in, I did a git log
> against the
> 
>  src/gnc-module/swig-gnc-module.c
> 
> file, having checked out the most recent commit on the maint branch,
> and the file alwasy has the uncorrected "out" not "our" in it.
> 
> Does that mean that the official 2.6.21 tarball wasn't built against
> the commit with the hash that is visible in the autogenerated file

No. If building from a git repo swig-gnc-module.c is a generated file. That generated file will be 
included in the dist tarballs together with all the other swig generated files.

So if you generate dist tarballs with different versions of swig installed on your system, they 
may indeed have different swig-generated files.

For the record, starting with gnucash 4.0 we will no longer ship the swig generated sources in 
our dist tarballs, aligning tarball builds a bit more closely with git builds.