[GNC-dev] swig as permanent build requirement (was: Re: [GNC] UK VAT and "Making Tax Digital")

[Geert Janssens]

Op donderdag 16 mei 2019 05:24:04 CEST schreef John Ralls:
> > On May 15, 2019, at 7:49 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op woensdag 15 mei 2019 15:43:43 CEST schreef John Ralls:
> >> OK, that all sounds reasonable.
> >> 
> >> Regards,
> >> John Ralls
> > 
> > Glad you agree.
> > 
> > Remaining question is when to introduce this ? Would you do it for the
> > next
> > stable release or on master ? I'm inclined to go for the latter as not to
> > trip up too many distro packagers in the middle of a stable series.
> 
> I agree that we don't want to mess with the release build requirements
> during a stable series, but why not continue to pre-swig the release
> tarballs?  We can distinguish between swig-foo.c being in srcdir or not to
> decide whether swig is required. If it's there then we're building from a
> pre-swigged tarball; if not then we run swig. As long as the builder
> follows our advice and builds in a separate directory there's no conflict
> as swig-foo.c goes in builddir. If that bugs you then we can remove that
> behavior and swigging from the dist target for 4.x.
> 
I am aware I'm digging into a corner case here. The build in general works 
fine once set up according to our guidelines. My itch is in the "once set up 
according to our guidelines" and whether we can stretch that a bit. This is 
primarily focused at making a newcomer's life easier and by consequence lower 
the support burden a little.

>From that point of view I think testing on the presence of swig-foo.c in the 
srcdir is fragile.

For starters despite our advice several people still prefer to build in 
source. It appears this notion of a separate build directory is not ingrained 
deeply into the development ecosystem.

Secondly it introduces a different build behavior between building in-source 
or out-of-tree. The former would run swig once and then never again while the 
latter (ideally) runs swig whenever needed. That's a support nightmare.

Note the primary reason we currently propose to build in a separate directory 
is to make it easier to start afresh. Just drop the build directory and you're 
good to go. Adding behavioral differences that are not really needed is 
another level which I would prefer to avoid.

> Versioning of releases shouldn't change either: We want the release to be
> gnucash-3.6 and a post-release Github tarball to build
> gnucash-3.6-whatever.

I agree on the concept. But that's not what happens right now: download a 
(non-release) github tarball and it will fail to build (even when forcing the 
swig run). Github's source tarballs don't provide the necessary details to 
generate a build id - there's no git history to work from, nor a gnc-version.h 
file which we do have in our release tarballs. And our build script will 
simply refuse to build in that case.

I think that's a bit restrictive. IMO tt could just as well emit a cmake 
warning about failing to generate a detailed build id, set it as 3.6-unknown-
rev and run the build anyway. In addition we could print a run-time warning 
similar to our development version message. It could explain why the build id 
mentions unknown-rev and explain that makes it harder to provide support as we 
can't tell the exact source revision. We could even print out a set of 
commands to run in the source directory to convert it into a git work tree 
(git init/git remote add/...). Something like that. I think this may be more 
encouraging to newcomers: they did manage to complete a build, they have 
gnucash running. And while running it for the first time they get advice on 
how to proceed to a more supported building method.

Regards,

Geert