Swig code generation - git src vs tarball src

[Geert Janssens]

On Monday 30 March 2015 10:15:10 John Ralls wrote:
> > On Mar 30, 2015, at 6:53 AM, Geert Janssens
> > <geert.gnucash at kobaltwit.be> wrote:> 
> > 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,
> 
> I think it’s still worthy because we have a lot of dependencies and
> saving one makes it easier to build GnuCash from source. Changing it
> now in maint would break distro scripts unnecessarily, so if you
> really feel strongly about it you should pull it out from master
> only.
> 
I don't feel strongly about it. Sometimes I just prefer to question old 
decisions just to verify if they are still valid. The swig story struck 
me as one such old decision. I was mostly wondering if this was 
originally done because swig was unstable or not available on all 
platforms we support. Since it is now on all platforms I wanted to 
double-check.

And indeed such a change shouldn't be done in maint.

> That said, I agree that it would be better to have configure check for
> swig-runtime.h and if it’s not present make sure that swig is
> available and enable running it as we now do for VCS builds.
> 
That option also crossed my mind and I actually like this as a good 
middle ground. When/If I get around to it I'll see if I can add this in 
master. To remind me I have created an enhancement request [1]

> I don’t understand why you can’t just have the nightly build make the
> rpm from git. Is that a limitation on Fedora’s packaging tools?
> 
That's how I understand it yes. A nightly build for Fedora should be an 
installable rpm. The only way I know to make an rpm is to call rpmbuild. 
This can either take a .spec file or a tarball as input. But in both 
cases it will want to run a build on that tarball. And since we 
currently don't support building from a tarball created from the git 
source tree, I can't feed it a git source tree directly. I first have to 
build a dist tarball and feed that into rpm build.

Regards,

Geert


[1] https://bugzilla.gnome.org/show_bug.cgi?id=747049