Op dinsdag 14 mei 2019 16:38:22 CEST schreef John Ralls: > Maf, you need to delete your source directory and clone the repository. See > https://wiki.gnucash.org/wiki/GnuCash_Sources#Developers_Source_Code > > This failure is not at all odd. Building from a Github-generated tarball is > guaranteed to fail because it's not pre-swigged and our buildsystem only > invokes swig if it detects that it's using a git clone.
I thought I had changed that, but I see not quite as I remembered: our build system will enable the swig bits if it detects a git clone and disable it otherwise. You can force a swig run or not by setting GENERATE_SWIG_WRAPPERS to "on" or "off" on the cmake command line (like -DGENERATE_SWIG_WRAPPERS=on). That's not the same as running swig automatically when the wrappers weren't generated yet. > We should change > the build so that it detects the absence of the swigged source files and > either sets up to run swig or fails with an intelligible error that one is > trying to build in a way that's not supported. I think the former makes > more sense. > I think option one is pretty close to just making swig a required build dependency and just have the build system treat the swig interface files as ordinary source file always. Perhaps it's time to drop this special casing for the swig wrappers. We currently base it on whether or not the build is started from a git clone, but there's not really a link between swig and git sources (there is a link between git and our version determination, more on that later). And clearly our current selection mechanism has a gap: we have defined behavior for building from a git clone and for building from a release tarball, but we have undefined behavior for every other source option (github generated tarballs or zip files being the most obvious example). IIRC the motivation for this split behavior was that swig used to be a fairly exotic dependency, too unstable, not available on many platforms. So requiring everyone to do a swig run would raise the bar for potential contributors. I think those days are gone: - According to https://repology.org/project/swig/versions a fairly recent version of swig is packaged for plenty of distros, including those we care about. - The number of build failures we see because of swig are rare. The ones we do get are typically because of interface changes we're not detecting. This is really an issue with our build system though, not swig. Hence my vote to make swig a mandatory build requirement and fix our dependency trees. Back to the version determination: our current build system depends on the presence of either a gnc-version.h file or a git clone to generate a trackable build id. The gnc-version.h file is present in our release tar balls but not in git (as it changes with every git commit). It's hence not available in tarballs or zip files generated by github. So if Maf would have set the GENERATE_SWIG_WRAPPERS switch in cmake, the build would still have failed because it couldn't have determined the exact commit the build was started from. That's the second and final bit that prevents us from just building from the git generated zip files/tarballs. For this bit as well I would propose to remove the blocking behavior and instead mark up the build id in such a way that it's clear the exact build source could not be determined (like instead of adding the git describe output, set it to unknown/undetermined/whatever). Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
