[GNC-dev] broken build dependencies within Gnucash on Windows project

Mon May 27 15:22:47 EDT 2019

Bug fix on maintenance branch: That's the most common build scenario indeed, just build the current GnuCash maint branch. Totally orthogonal to building an old release exactly as it was at the time of the release. If you want to build a particular tag e.g. 3.1, edit jhbuildrc and add 
  branches['gnucash-git'] = (None, '3.1')
somewhere, or start a jhbuild shell and do it manually. 

What I don't see much point in attempting to build is GnuCash 3.1 using the exact same dependencies as those in the release bundle. Although you could get partly there with the built dependencies, you'd also need to set up the MinGW64 packages to what was on the build server that day. 

The jwbuild-based build system never built 2.6.x or earlier; that was the old system I cleaned out a couple of weeks ago.

You're right and I'm wrong about patches directories, at least according to the docs. I'll try changing to relative paths after I get Guile beaten back into submission.

Regards,
John Ralls

> On May 27, 2019, at 10:13 AM, Dale Phurrough <dale at hidale.com> wrote:
> 
> Benefit to build old releases?  Bug fixes on maintenance branches is the most common scenario. For example when the community released 2.x and 3.x versions in parallel. There is always a need to build old versions. Even if it is for someone on the Internet that wants to hack on Gnucash on their Windows XP machine. ;-)
> 
> Caveat, I could be misreading your reply. It seems to suggest that you think the current build process for Windows works. It doesn't. 100% fails and blocked.
> Only the lucky few people (like you and your build server probably) that setup the build environment sometime before April 2019, and compiled all the dependencies like Guile so that they are cached locally, can compile Gnucash on Windows.
> For the rest of us (me personally, the dockers, and every other new person/system), we can't. Because of the version issues that we can't compile the core dependencies like Guile. Until those compile, we can't get to the stage to compile Gnucash itself.
> 
> jhbuild can have absolute paths to the patches. Lets use the current set of patches to opensp, guile, etc. that are the current build blockers. Here's a loose process. Likely doesn't work, its just a rough flow
> 1. The TARGET environment variable defines what branch of gnucash to build. There needs to be a similar variable for what branch/commit of the build process. Lets call it BUILDER_TARGET and it contains a branch, tag, or commit.
> 2. The bootstrap works by default to clone everything from master. If BUILDER_TARGET is defined, then it clones and checkout that BUILDER_TARGET. The cloning is in a well-known location as it is already done today, e.g. C:\gcdev64\src\gnucash-on-windows.git
> 3. The jhbuild module <patch> tags point to the relative/absolute location of the patches in that well-known location on the hard drive. No internet needed.
> 
> Modules like libdbi pull from sourceforge with version numbers. That's good and "pins" that version dependency. Now jhbuild needs to pin the patch that is applied to it. The glue binding them together is the gnucash.modules file. That file is in the repo so it is versioned *and* it is stored in the same directory as the patches. Hurray! It is in the same git clone already checked out in step 2 above. No need to go to the Internet. So it is possible to use relative references to the libdbi patches like...
> <patch file="patches/libdbi-0.8.3.patch" strip=1>
> or something similar.
> With that approach and libdbi as the example, gnucash.modules of a specific commit references and downloads specific versioned sourceforge URIs, and applies specific versioned patches that exist in the folder on the hard drive of that git checkout.
> 
> That's just an example. I hope it highlights there are quite simple solutions to some of the versioning problems.
> 
> --Dale
> 
> 
> On Mon, May 27, 2019 at 4:52 PM John Ralls <jralls at ceridwen.us> wrote:
> 
> 
> > On May 27, 2019, at 4:31 AM, Dale Phurrough via gnucash-devel <gnucash-devel at gnucash.org> wrote:
> > 
> > Hi all. I found a philosophical issue that leads to an ongoing series of
> > Windows build process bugs. Want to bring it to this forum. I believe it
> > needs discussion on approach, so that bugs can be created and holistically
> > fixed for now/future.
> > 
> > The Windows build process at
> > https://github.com/Gnucash/gnucash-on-windows since
> > Gnucash 3.5 (didn't look further back) relies on a single bootstrap file.
> > The bootstrap downloads resources (scripts, patches, repos) within the
> > control (and hosted by) the Gnucash project.
> > 
> > The issue is a favorite -- dependency management. This bootstrap is
> > downloaded from GitHub. Naturally, the bootstrap changes over time and
> > therefore has an inherit version. That bootstrap is downloading resources
> > within this project using *unversioned* URIs.
> > 
> > Bad news====
> > The bootstrap used for Windows GnuCash 3.5 doesn't work because it relies
> > on GitHub URIs that no longer exist in the current master branch. :-( The
> > more current bootstraps on master don't work also because of related URI
> > not found bugs and patches that don't match other downloaded resources.
> > Currently, the Windows build setup is broken. It is not possible to
> > bootstrap and setup a new Windows Gnucash build for 3.5 or later.
> > 
> > Everyone following? Here's one of the series of bugs
> > https://bugs.gnucash.org/show_bug.cgi?id=797252
> > The fixes (like in that bug above) still have the versioning problem. These
> > fixes are fragile and break easily.
> > 
> > Good news====
> > This issue is inside the project. We can fix it. This community controls
> > the project, the code, and the download resources. :-)
> > 
> > Brainstorming ideas (not ready for implementation)...
> > 
> >   1. Put the commit version needed in the URI. For example, if your
> >   bootstrap is from commit 123abc, then download resources from that same
> >   commit.
> >   2. Use git clone, checkout, etc. with versions.
> >   3. Put the download in a package manager and the bootstrap downloads the
> >   specific version it needs.
> 
> I'm not sure that there's any benefit to retrospectively building old releases; we keep a long history of releases and nightly builds at https://code.gnucash.org/builds/win32, and all of the releases for both Windows and MacOS are at https://sourceforge.net/projects/gnucash/files.
> 
> For normal use, just keep your local gnucash-on-windows repo current. If you want to automate builds, e.g. in your docker, use buildserver/build-package.ps1. Before building that gets both your MinGW64 and gnucash-on-windows repo up-to-date.
> 
> It *would* be nice to be able to easily build from an arbitrary checkout of gnucash-on-windows but jhbuild wants URIs or absolute paths to the patch files, so the choice is to either be able to put gnucash-on-windows wherever you want or to get patches locally instead of from Github.
> 
> Regards,
> John Ralls
> 