[GNC-dev] [GNC] UK VAT and "Making Tax Digital"

[John Ralls]

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

OK, that all sounds reasonable. 

Regards,
John Ralls