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

John Ralls jralls at ceridwen.us
Thu May 16 10:05:56 EDT 2019

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

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

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

John Ralls

More information about the gnucash-devel mailing list