> On May 16, 2019, at 1:39 AM, Geert Janssens <geert.gnuc...@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.gnuc...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
