On Monday 30 March 2015 10:15:10 John Ralls wrote: > > On Mar 30, 2015, at 6:53 AM, Geert Janssens > > <geert.gnuc...@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.gnuc...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
