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

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

Regards,
John Ralls