Re: [gtk-osx-users] Setting up JHBuild environment and forcing builds if patches have changed

[John Ralls <jralls ceridwen us>]

> On Jan 23, 2022, at 11:45 AM, Lukas Oberhuber via gtk-osx-users-list <gtk-osx-users-list gnome org> wrote:
>
> Hi,
>
> Two questions:
>
> 1. How do I set up the JHBuild environment to then run my own build, for a package?
>
> 2. How can I configure JHBuild to detect that I've made a change to the patches I've included on a package. 
> This is especially critical for CI builds where I find I have to make a commit with 'jhbuild buildone 
> --force package_name' because it otherwise won't detect the change (and I have to use caching because the 
> build otherwise times out so full rebuilds are not an option).

The way I do #1 is to build whatever package I'm going to work on, then run `jhbuild shell && cd $PREFIX 
../build/package && make uninstall` (or ninja uninstall if it's a meson project). You could also do `jhbuild 
build --skip foo foo` to build all of the dependencies without the package, but then you have to set up your 
own build directory and run the configuration (i.e. autogen.sh/autoreconf/configure, cmake, meson, ...) by 
hand. You'll need to do that anyway if you want to test different config options or build systems and it's 
sometimes a good idea to just clear out the build directory and reconfigure from scratch.

In another Terminal tab I cd to the corresponding src/package, though I don't usually start a jhbuild shell 
for that so I can't use $PREFIX. Aim your favorite editor at the same source directory. Now you can edit 
files in the editor, use the source-directory terminal tab for git, and run builds in the build-directory tab.

Changing patches on tarballs is a bit cumbersome because you have to stop the build and choose 6 - delete 
directory and start over. The only other way to get jhbuild to reload a tarball and apply different patches 
is to delete the source directory before starting jhbuild. The easiest way to deal with that is to set up a 
git build of that dependency and point the repo at a bare repo on your machine. Then you can push changes to 
that repo and jhbuild will pick them up without extra effort. That has the added advantage that you've got a 
git safety net for your work.

You don't want to use jhbuild in a CI recipe. I prepare a tarball of the dependencies by running jhbuild with 
a prefix pointed at a directory tree that mirrors the one that the CI runner uses. `jhbuild build --skip foo 
foo` builds and installs all of the dependencies. Tar up the prefix and put the tarball somewhere that the CI 
runner can find it and add a step to your CI recipe to retrieve and un-tar it. Build your project using the 
CI runner's build recipe.

Regards,
John Ralls