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

[Geert Janssens]

On maandag 27 mei 2019 19:13:33 CEST Dale Phurrough via gnucash-devel 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.

I don't think that's what John was alluding at all :)

> It doesn't. 100% fails and blocked.

Indeed currently due to the guile build failure. I can reproduce. We are using 
a guile source that is patched by John and then uploaded to our own 
sourceforge page. It may be John missed applying a patch that is on his local 
machine. I'll leave that for him to figure out.

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

Mine is on D:\gcdev64
And that's John's point: the base directory can currently be different for 
everybody. If we want to keep supporting this and you do want to use local 
filesystem paths, that would mean we'd have to parameterize the 
gnucash.modules files. Because in that file, paths can only url's (what we use 
now) or absolute filenames. As our build system gives the user the freedom to 
install the gnucash-on-windows repo wherever convenient, we can't hardcode 
absolute filenames to that gnucash-on-windows repo locally.

> 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.
> 
They have to be absolute. And there's no well-known absolute location. Only 
well-known relative locations, relative to wherever the user chose to install 
gnucash-on-windows.

> 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.
Have you tried this already ? If I understood John's reply this has to be an 
absolute path.

> That's just an example. I hope it highlights there are quite simple
> solutions to some of the versioning problems.

If relative paths work yes, otherwise no.

Having said all that, I have suggested in the past we should at least tag the 
commits we use to successfully build gnucash releases. That is the commit we 
use to build the 3.5 release should equally be tagged 3.5. That should help in 
at least reproducing tag builds from scratch. The builds inbetween releases as 
far as I'm concerned can be expected to build only with the most recent commit 
on gnucash-on-windows, until the next tag is added.

Geert