[GNC-dev] [GNC] UK VAT and "Making Tax Digital"
jralls at ceridwen.us
Wed May 15 09:43:43 EDT 2019
> On May 15, 2019, at 2:16 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 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
> 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
> - 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).
OK, that all sounds reasonable.
More information about the gnucash-devel