[GNC-dev] [GNC] UK VAT and "Making Tax Digital"
geert.gnucash at kobaltwit.be
Wed May 15 05:16:26 EDT 2019
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
> 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
> 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
- 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
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).
More information about the gnucash-devel