Op zaterdag 10 maart 2018 18:00:29 CET schreef John Ralls:
> But let’s back up a bit. I think we’ve pretty thoroughly established that
> making build decisions based on the presence or absence of a “.git”
> directory in the source directory is fragile. It’s also unusual; I don’t
> think I’ve seen any other build system that does that.
> 
> Let’s catalog everything that we’re switching with BUILDING_WITH_VCS:
> 1. Generate gnc_vcs_info.h and GNC_VCS_REV
> 2. Generate Changelog
> 3. Set GENERATE_SWIG_WRAPPERS (can be manually overridden)
> 4. Generate gnucash.pot
> 5. Include (the mostly useless) design.info <http://design.info/> in a
> dist-generated tarball.
> 6. Find gnc_vcs_info.h since its location (srcdir
> vs. builddir) depends on whether it’s generated of packaged.
> 7. Configure where to get files (srcdir vs. builddir) when making a tarball.
> 
> 6 and 7 can be done using cmake’s find_path function as I did yesterday in
> fbb172d09.
I remember thinking "clever..." when I saw that commit passing by. Agreed this 
would be a good improvement.

> ISTM 5 shouldn’t depend on whether one is building from vcs. IMO
> it shouldn’t be done at all, but that’s a separate issue.
> 
I remember I hesitated when last working on the build system in this area. I 
treated the design.info document as swig wrappers: by adding it to the dist 
tar ball we would avoid makeinfo as build dependency for packagers.
From what I understand this file is hopelessly outdated. So it seems to me 
distributing it doesn't make much sense. So let's start by dropping it from 
the dist tarball.

Then what should happen with it ? Is anyone willing to salvage the useful bits 
and copy them over to our wiki ? That looks like a more appropriate place in 
2018.

Until that's done we can keep the build rule, but make sure it's not added to 
any default target as a convenience to the volunteer that will do the 
migration work.

> Deciding whether to generate swig wrappers and gnucash.pot rather depends on
> what one is doing. A distribution tarball contains swig wrappers and
> gnucash.pot, but those can be invalidated by changes to the source. It
> seems to me that it would be more robust if we check for the presence of
> gnucash.pot and one of the swig wrapper files in srcdir and set the default
> values of GENERATE_SWIG_WRAPPERS and GENERATE_POTFILE accordingly, which
> the builder could override from the cmake command line.

While we're thinking out of the box I'm questioning the usefulness of 
distributing the swig wrappers. I know our stance so far has been it's an 
extra dependency with no maintainer for the guile submodule. On the other hand 
however we've been successfully generating our swig wrappers on all supported 
platforms for years. And even if swig doesn't have a dedicated guile submodule 
maintainer it does have a rather comprehensive unit test suite. The last issue 
with swig I remember was in the migration from 1.8 to 2.0. In addition we're 
probably finding such issues fairly quickly ourselves as we tend to build with 
very recent versions of swig and guile.
So what would be the added complexity for downstream if we chose to have them 
always generate the swig wrappers ?

This is slightly different for gnucash.pot IMO. That file is targeted at 
translators, which usually are not developers. So asking them to set up a 
build system with the necessary dependencies would be a very high barrier for 
many potential translators. So I'd keep the GENERATE_POTFILE option.

> 
> ChangeLog is a bit harder: It’s not possible to generate a correct one
> unless the source is a clone of our git repository. It’s arguable that it’s
> obsolete: The complete history is easily obtained from the repo if someone
> is interested. We currently generate it as part of every build from vcs,
> but perhaps it should be moved to the dist target--or maybe it should be
> simply dropped.

We can replace it with a generic Changelog pointing at the git history 
somewhere online. That would be github as things currently stand as we don't 
provide a webinterface to the git repositories at code.gnucash.org.

But I'd be totally fine with us no longer generating a Changelog. Unless some 
downstream package rules require it. If so, packagers please speak up.

> 
> Which leaves setting the version. When building from a release tarball we
> want to use the plain release number as the version, e.g. GnuCash-2.7.5;
> when a build isn’t from a release tarball we want to indicate that.
> Ideally, of course, someone building from a modified release tarball would
> also do that but as Geert observed it’s not possible for us to enforce
> that. There are two other problems: First, as Geert pointed out when he
> began the discussion, it’s not unreasonable for someone to take a tarball
> and create a new repository from it. As discussed already that repo won’t
> necessarily be a git one, thus breaking the versioning code, but even if it
> is the retrieved commit will be confusing because it won’t be one from the
> canonical repository.
> 
> One possible solution would be to test the value of `git remote -v 2>
> /dev/null | grep "origin.*(fetch)"`. If it’s either code or the Github
> mirror then we set the version from `git describe`, otherwise it’s the
> ${VERSION} as set in CMakeLists.txt.

That's certainly a good start. We should keep a way to override this though. 
Distros often add '-x' extensions to the version number to indicate their own 
patch level. The GNUCASH_BUILD_ID was provided for that purpose.

Aside from a version number we also use commit date in various places. This is 
to strike a balance between the downstream desire to produce reproducible 
builds and informing the user of how old their gnucash installation is. This 
may actually be a good reason to keep the multi-vcs support in gnc-version-
info.sh. However I think it needs revision. I'm not sure we can extract the 
date from all the vcs types currently tested in there.
And that leaves us with the question of what date to use in case the build is 
not from a vcs based source tree. Should we allow an override similar to 
GNUCASH_BUILD_ID and leave it up to the builder ?

Geert


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to