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. > 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. Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
