Swig code generation - git src vs tarball src

[Geert Janssens]

On Saturday 28 March 2015 12:56:10 John Ralls wrote:
> > On Mar 28, 2015, at 3:16 AM, Geert Janssens
> > <geert.gnucash at kobaltwit.be> wrote:
> > What is the original reason it was implemented this way ? Or put
> > differently is there (still) a good reason to avoid on the fly swig
> > code generation for a (release) tarball build ?
> 
> I wasn’t actually around for it, but I suspect that the reason was to
> avoid having SWIG as a dependency for building release tarballs. I
> think that that’s still worthy.
> 
Care to motivate this some more ?

In my mind swig is just one conversion step from a source file (a *.i 
file) to an intermediate build file (which happens to be a C source file 
in this case). What's bad about depending on a build tool like swig even 
in release tarballs ? Should we then also change the build system to not 
distribute the iso-currencies xml file, because that means we are 
depending on xsltproc ?

> I also think that it’s good that the build from a tarball based on a
> random commit fails. Since that tarball doesn’t contain any version
> information other than what’s in configure.ac, the resulting GnuCash
> will look like the last release which could produce some confusing
> bug reports..

I agree the basic tar build should fail. And it does - exactly when it 
comes to gathering the extra version information.

That is however unrelated to whether or not swig should be a permanent 
dependency or not. That was rather a question that occurred to me while 
working on a nightly build system for Fedora.

Also while the git tarball indeed doesn't contain extra version 
information (such as commit hash the tarball was created from) the code 
that created the git tarball does have this information available and 
could add this to the subsequent build.

Keep in mind that my final goal is to provide nightly builds on linux 
distributions much like we do for Windows users. These will primarily 
serve to allow bug reporters to quickly test a fix without having to 
wait for the next release. Not every reporter is capable of building 
gnucash from scratch and expecting them to would seriously increase the 
barrier for entry.

My first experiments are on Fedora because that's the distribution I use 
daily.

I can set this up a nightly build with the code as it is already. It 
would roughly look like this:
git clone gnucash-repository (or git pull to update only)
build dist tarball (./autogen.sh; make; make dist)
use dist tarball to create srpm
build rpm from srpm

This means running the build twice
- once for the dist tarball
- and once to go from srpm to rpm.

The only crucial thing the first build does that can't be done during 
rpm build is gather extra version information to distinguish this build 
from a release build. As I already stated this information could be 
extracted at another phase in the nightly build.

Geert