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

Geert Janssens geert.gnucash at kobaltwit.be
Thu May 16 15:02:30 EDT 2019

Op donderdag 16 mei 2019 16:05:56 CEST schreef John Ralls:
> > On May 16, 2019, at 1:39 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op donderdag 16 mei 2019 05:24:04 CEST schreef John Ralls:
> OK, create a flag file that the dist target makes and isn't present
> otherwise. My objective is to find a way to get "almost-always-swig"
> without changing the requirements for building release tarballs so that we
> don't have to wait until 4.x, at which point we can take away the
> "almost-always".

Ok, that's a useful paradigm shift that can work until the 4.x series.

> >> 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.
> I meant "whatever" as a literal, not as the version number, the idea being
> that if building from a release tarball the build gets the release number;
> if building from git it gets the release tarball + the commit-date-and-sha
> as now, and if neither it gets "whatever", determining the version from
> CMakeLists.txt.
> "Whatever" might be too flippant. Perhaps "modified" would be better.

Right, I misunderstood your "whatever". So we're actually really proposing the same thing 
for the build id part, just using different words. The rest of my text was only proposing a few 
optional extra grips for new comers.


More information about the gnucash-devel mailing list