[GNC-dev] swig as permanent build requirement (was: Re: [GNC] UK VAT and "Making Tax Digital")
geert.gnucash at kobaltwit.be
Thu May 16 04:39:44 EDT 2019
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
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.
More information about the gnucash-devel