Swig code generation - git src vs tarball src

John Ralls jralls at ceridwen.us
Mon Mar 30 13:15:10 EDT 2015


> 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.

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.

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? 

Regards,
John Ralls




More information about the gnucash-devel mailing list