Author: chergert

In Builder, we landed a new feature for 3.24 that allows you to create a new terminal inside the application runtime. If you’re building against your host system, then this is nothing special. If you’re building against jhbuild you’ll get a shell inside of that (but again, nothing really special).

However, if you’re building for a flatpak runtime, such as org.gnome.Platform, your shell will look completely different from your host system. Instead, it will be what the application sees at runtime. (Okay, it’s actually what it sees at build time, but the SDK is just the Platform with compiler bits, headers, pkg-config, and such).

• ctrl+shift+t for a terminal on your host
• ctrl+alt+shift+t for a terminal inside your application runtime

So here is an image of a shell in the host system on left and the runtime on the right. This makes it very convenient to figure out what your application is seeing during execution and audit the files you need to remove in your cleanup phase. Or maybe you just want to explore!

If you are not using Builder, you can explore a SDK or runtime with flatpak run org.gnome.Sdk. Additionally, if you’re interested in exactly what your application sees after you have packaged and installed it, try:

flatpak run --command=bash com.example.MyApp

Adding -d to the above will give you the SDK instead of the runtime. This is much closer to what Builder will give you.

flatpak run -d --command=bash com.example.MyApp

We are really starting to be able to do cool things with Builder these days. Just install our Builder Nightly and you can build plenty of GNOME apps.

I should note that Builder doesn’t yet have the ability to install your application but I intend for this to land before 3.24.

Here is a screenshot sequence of me using Builder installed from flatpak to build and test GNOME ToDo, also in flatpak.

I wanted a bit of a distraction this evening, so I put together a quick valgrind plugin. Just select “Run with Valgrind” from the drop down menu and it will make sure your program is run using the venerable valgrind.

If valgrind isn’t available in your runtime (host, jhbuild, flatpak, etc) you wont see the menu item. But thankfully the org.gnome.Sdk runtime we use to build GNOME apps has it, so for many of you it should Just Work™.

One of the core features of Builder is, well, building. So we need to provide the best experience we can. That means we need wide support for build systems and languages. How we get from source code to a product can vary in a multitude of ways.

For example, you might need to alter how you launch programs to run inside a container. You might need access to headers that only exist in the SDK and not the application runtime. You might even need to download or build dependencies for your project at a given point. Furthermore, this could all change based on what plugins you’ve chosen to enable in your Builder environment.

When I set out to create Builder, I knew that I wouldn’t be able to see all the possibilities that Builder needs to handle. So I explicitly avoided designing an abstract solution until I understood the problem better. But I think we understand the problem well enough now. So over the winter holiday I started putting together the design of IdeBuildPipeline.

The pipeline is a one-directional series of build phases. Each phase can have stages attached to it. Builds progress in the order of their attached stages, each of which can be an asynchronous operation. We only need to advance the build up to the requested phase. If the IDE detects something has changed, it can invalidate various phases of the pipeline causing them to be executed again at the next build request.

Plugins should implement the IdeBuildPipelineAddin interface to register any necessary pipeline stages.

Generally, build stages are an IdeSubprocessLauncher, but you can implement custom IdeBuildStage subclasses to do more fancy things. For example, if you need to download something, you might add an IdeBuildStageTransfer and you’ll see the transfer show up in the transfers window.

Of course, some problems are complex enough where we don’t know if they are invalidated upfront and the build stage may query some external resource. For that, the IdeBuildStage class can implement the query signal. Of course we should strive to perform blocking operations asynchronously so consider pausing the stage until your asynchronous request has completed.

We know how difficult it is for newcomers to get started so we’ve taught Builder how to download Flatpak runtimes and SDKs based on your project configuration. That means that you can omit those flatpak install commands from your “project setup” guide. Just clone the project URL and click Build, we’ll take care of the rest.

Thanks to this new design, implementing a build system is much easier. To prove this, I finally implemented a basic cmake+ninja plugin in a matter of an hour. Check it out here. If you’d like to write CFLAG extraction for cmake, we could use that still!

We now have support for autotools, cargo, cmake, and meson build systems.

I’ve been rather quiet recently working on new features for Builder. But we managed to just release Builder 3.22.3 which is full of bug fixes and a really new important feature. You can now meaningfully target flatpak when building your application. Matthew Leeds has done this outstanding work and it is really going to simplify how you contribute to GNOME applications going forward.

I’m really happy with the quality of this feature because it has shown me where our LibIDE design has done well, and where it has not. Of course, we will address that for 3.24 to help make some of the UI less confusing.

Without further ado, how to clone, build, run, and hack on Polari without so much as a toolchain installed on your host system. The only prerequisite is to get GNOME Builder 3.22.3 from the GNOME flatpak repository (or your distribution if it is up to date).

Edit: Your system might require the installation of flatpak-builder if it is in a separate package (such as on Fedora 25).

# Get things ready on Fedora 25
sudo dnf install flatpak-builder

# Download GNOME's nightly SDK for development.
# We'll automate this for GNOME 3.24.
flatpak --user remote-add gnome-nightly \
https://sdk.gnome.org/gnome-nightly.flatpakrepo
flatpak --user install gnome-nightly org.gnome.Sdk master
flatpak --user install gnome-nightly org.gnome.Platform master