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

[Dale Phurrough]

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
>
>