Op donderdag 16 mei 2019 16:05:56 CEST schreef John Ralls: > > 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: > 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. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
