List items
Items from the current list are shown below.
Blog
10 Apr 2024 : 212 #
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:
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.
For reference, here are the targets that I have installed in my SDK:
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:
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:
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:
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
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-aarch64The 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-definedThe 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 snapshotThe 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-aarch64Now 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 snapshotThat'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-aarch64This 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-aarch64Ultimately 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_workaroundThis 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.*.rpmAnd run them:
$ harbour-webviewAnd 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_workaroundNow 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.soBut, 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.
Comments
Uncover Disqus comments