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

[Geert Janssens]

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