flypig.co.uk

I'm changing tack today. After spending weeks reviewing the offscreen render initialisation code, I'm now turning my attention to the ESR 78 code. That may sounds a bit weird, but bear with me.

In order to check whether changes to the build ought to be resulting in particular consequences in the running software, I'm wanting to make some changes to the ESR 78 code to see what happens there. You could say it's an experimental approach to debugging the ESR 91 code. But to do this I need to build ESR 78.

The change I want to make is simple. Over recent days we were looking at the CompositorOGL::EndFrame() code. This is called at the end of the render process in order to swap the back buffer with the front buffer and allow the latest updates to be shown onscreen. Before this swap happens I've added two lines of code, right at the top of the method:

void CompositorOGL::EndFrame() {
  AUTO_PROFILER_LABEL("CompositorOGL::EndFrame", GRAPHICS);

  mGLContext->fClearColor(0.0, 1.0, 1.0, 0.0);
  mGLContext->fClear(LOCAL_GL_COLOR_BUFFER_BIT | LOCAL_GL_DEPTH_BUFFER_BIT);
[...]

The two added lines are the fClearColor() and fClear() calls. Both of these combined should clear the buffer and leave it a nice cyan colour. That's assuming everything is working as I expect it to. If this works on ESR 78 then I can transfer the same code to ESR 91 to see whether it will work there. If it does, then I'll know the process of showing the surface onscreen is working and I should focus on the page rendering code. If it doesn't then it will indicate the surface render is broken and I should continue focusing my efforts there.

So I'll need to set off a build of the ESR 78 code with these minor changes. Apart from the build being a lengthy process, it'll also involve configuring the build environment correctly. The sfdk build tool has some nice features for separating out different build environments and configurations using snapshots and sessions. I'm going to use both. It's quite important to get all this right though. Otherwise there's a risk I'll clobber my ESR 91 build configuration which will mean, quite apart from having to reconfigure things back, I may also have to do a full rebuild of all the many packages that have been touched by the ESR 91 changes.

For context, here's the build configuration I'm using for ESR 91. The important things to note are the output-prefix which is where the final packages end up and the target which combines both the choice of processor and the list of packages that are installed in the environment where the build takes place.

$ sfdk config
# ---- command scope ---------
# <clear>

# ---- session scope ---------
# <clear>

# ---- global scope ---------
output-prefix = /home/flypig/RPMS
device = kolbe
target = SailfishOS-devel-aarch64

The output-prefix is also important because it's used to override packages in the target. In other words, any packages it finds in this output directory will be used in preference to packages that are part of the target environment.

For reference, here are the targets that I have installed in my SDK:

$ sfdk tools target list
SailfishOS-3.4.0.24-aarch64  sdk-provided
SailfishOS-3.4.0.24-armv7hl  sdk-provided
SailfishOS-3.4.0.24-i486     sdk-provided
SailfishOS-4.5.0.18-aarch64  sdk-provided,latest
SailfishOS-4.5.0.18-armv7hl  sdk-provided,latest
SailfishOS-4.5.0.18-i486     sdk-provided,latest
SailfishOS-devel-aarch64     user-defined
SailfishOS-devel-armv7hl     user-defined
SailfishOS-devel-i486        user-defined

The devel targets are actually just copies of the 4.5.0.18 targets which I use for convenience to avoid having to remember which version is the latest. Here are the snapshots I have available to use with these:

$ sfdk tools list --snapshots
SailfishOS-3.4.0.24                          sdk-provided
├── SailfishOS-3.4.0.24-aarch64              sdk-provided
│   └── SailfishOS-3.4.0.24-aarch64.default  snapshot
├── SailfishOS-3.4.0.24-armv7hl              sdk-provided
│   └── SailfishOS-3.4.0.24-armv7hl.default  snapshot
└── SailfishOS-3.4.0.24-i486                 sdk-provided
    └── SailfishOS-3.4.0.24-i486.default     snapshot
SailfishOS-4.5.0.18                          sdk-provided,latest
├── SailfishOS-4.5.0.18-aarch64              sdk-provided,latest
│   └── SailfishOS-4.5.0.18-aarch64.default  snapshot
├── SailfishOS-4.5.0.18-armv7hl              sdk-provided,latest
│   └── SailfishOS-4.5.0.18-armv7hl.default  snapshot
├── SailfishOS-4.5.0.18-i486                 sdk-provided,latest
│   └── SailfishOS-4.5.0.18-i486.default     snapshot
├── SailfishOS-devel-aarch64                 user-defined
│   └── SailfishOS-devel-aarch64.default     snapshot
├── SailfishOS-devel-armv7hl                 user-defined
│   └── SailfishOS-devel-armv7hl.default     snapshot
└── SailfishOS-devel-i486                    user-defined
    └── SailfishOS-devel-i486.default        snapshot

The SailfishOS-devel-aarch64 target is the one I use to build ESR 91 against, but that in practice this gets cloned as SailfishOS-devel-aarch64.default for the actual build.

So that's my current setup for ESR 91. For ESR 78 we want to tweak this a little. Like the SailfishOS-devel-aarch64 target we want to use a snapshot of the SailfishOS-4.5.0.18-aarch64 target for our build, but unlike for ESR 91 we want the output-prefix option to be set to a folder in the build directory, so that we only use system packages.

Let's call our new snapshot SailfishOS-esr78-aarch64. Here's how we create it:

$ sfdk tools clone SailfishOS-4.5.0.18-aarch64 SailfishOS-esr78-aarch64

Now listing the targets we can check it was successfully created. I've removed some of the old targets I have installed on my machine for brevity.

$ sfdk tools list --snapshots
[...]
SailfishOS-4.5.0.18                          sdk-provided,latest
├── SailfishOS-4.5.0.18-aarch64              sdk-provided,latest
│   └── SailfishOS-4.5.0.18-aarch64.default  snapshot
├── SailfishOS-4.5.0.18-armv7hl              sdk-provided,latest
│   └── SailfishOS-4.5.0.18-armv7hl.default  snapshot
├── SailfishOS-4.5.0.18-i486                 sdk-provided,latest
│   └── SailfishOS-4.5.0.18-i486.default     snapshot
├── SailfishOS-devel-aarch64                 user-defined
│   └── SailfishOS-devel-aarch64.default     snapshot
├── SailfishOS-devel-armv7hl                 user-defined
│   └── SailfishOS-devel-armv7hl.default     snapshot
├── SailfishOS-devel-i486                    user-defined
│   └── SailfishOS-devel-i486.default        snapshot
└── SailfishOS-esr78-aarch64                 user-defined
    └── SailfishOS-esr78-aarch64.default     snapshot

That's created the snapshot, but I also need to update the configuration. There are a variety of different ways to do this, but this is the route I've chosen:

$ sfdk config --session output-prefix=${PWD}/RPMS
$ sfdk config --session target=SailfishOS-esr78-aarch64

This will reset the output target to its default of the RPMS folder inside the build directory and set the target to use our new snapshot. Now checking the configuration gives the following.

$ sfdk config
# ---- command scope ---------
# <clear>

# ---- session scope ---------
output-prefix = /home/flypig/Documents/Development/jolla/gecko-dev-project/
    gecko-dev/RPMS
target = SailfishOS-esr78-aarch64

# ---- global scope ---------
# masked at session scope
;output-prefix = /home/flypig/RPMS
device = kolbe
# masked at session scope
;target = SailfishOS-devel-aarch64

Ultimately I'd like to do partial builds, but to make sure everything is set up properly, especially the installed dependencies, I'm going to start by doing a full rebuild of the code.

$ sfdk build -d --with git_workaround

This will, as always, take a long time. Below is an abridged copy of the first few screens of output. Notice in this output that 47 new dependencies are installed as part of this build process. I'll need all of those for the partial builds as well.

NOTICE: Appending changelog entries to the RPM SPEC file…
Setting version: 
    78.15.1+git36+master.20240408074155.619a29e0d110+gecko.dev.4d734e782f53
Directory walk started
Directory walk done - 0 packages
Temporary output repo path: /home/flypig/Documents/Development/jolla/
    gecko-dev-project/gecko-dev/.sfdk/filtered-output-dir/.repodata/
Preparing sqlite DBs
[...]

The following 47 NEW packages are going to be installed:
  alsa-lib-devel                             1.2.8+git1-1.6.1.jolla
  autoconf213                                2.13-1.4.10.jolla
  bzip2-devel                                1.0.8+git2-1.6.4.jolla
  cairo-devel                                1.17.4+git1-1.6.2.jolla
  cargo                                      1.52.1+git4-1.9.1.jolla
  cbindgen                                   0.17.0+git4-1.12.5.jolla
  clang                                      10.0.1+git3-1.6.3.jolla
  clang-devel                                10.0.1+git3-1.6.3.jolla
  clang-libs                                 10.0.1+git3-1.6.3.jolla
  clang-tools-extra                          10.0.1+git3-1.6.3.jolla
  cpp                                        8.3.0-1.7.2.jolla
[...]
  zip                                        3.0+git1-1.6.6.jolla

47 new packages to install.
[...]

[...]

The build was astonishingly fast, less than three hours for everything, which must be some kind of record. That makes me rather suspicious, but let's see. The packages are all there; I'm able to transfer them to my phone:

$ scp RPMS/SailfishOS-esr78-aarch64/xulrunner-qt5-78.*.rpm 
    defaultuser@10.0.0.117:/home/defaultuser/Documents/Development/gecko/

And install them:

$ rpm -U xulrunner-qt5-78.*.rpm xulrunner-qt5-misc-78.*.rpm 
    xulrunner-qt5-debuginfo-78.*.rpm xulrunner-qt5-debugsource-78.*.rpm

And run them:

$ harbour-webview

And what do we get with this? A really nice looking cyan screen and nothing else. This is great: this is what I wanted to see.
 
I've made the same change to the ESR 91 code and the great thing is I can now kick off a new build of ESR 91 in a different snapshot without having to make any changes to the configuration. I just switch gnu screen sessions and kick the build off:

$ sfdk config
# ---- command scope ---------
# <clear>

# ---- session scope ---------
# <clear>

# ---- global scope ---------
output-prefix = /home/flypig/RPMS
device = kolbe
target = SailfishOS-devel-aarch64

$ sfdk build -d --with git_workaround

Now that the ESR 78 build has completed I'm also able to do partial builds. Usually — for ESR 91 — I would use the following to get into the build engine. I've left the prompt prefixes in to help make clearer what's going on, but I generally remove them when writing these entries as they make things a bit messy.

$ sfdk engine exec
[mersdk@ba519abb3e13 gecko-dev]$ sb2 -t SailfishOS-devel-aarch64.default
[SB2 sdk-build SailfishOS-devel-aarch64.default] I have no name!@ba519abb3e13 
    gecko-dev $

Now when I want to get into my new ESR 78 build target I'll do the following instead (I'll remove the prefixes again from now on):

$ sfdk engine exec
$ sb2 -t SailfishOS-esr78-aarch64.default
$

I can then perform a partial build using the following:

$ mv .git .git-disabled
$ source `pwd`/obj-build-mer-qt-xr/rpm-shared.env
$ make -j1 -C obj-build-mer-qt-xr/gfx/gl/
$ make -j16 -C `pwd`/obj-build-mer-qt-xr/toolkit
$ strip obj-build-mer-qt-xr/toolkit/library/build/libxul.so

But, that'll be useful for another day. As for today, the ESR 91 build is still running and I'll need to wait for that to complete before I can test my hypothesis. By the looks of things, that'll have to wait until tomorrow, so that's it for today.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.