{"id":540,"date":"2020-06-30T15:47:01","date_gmt":"2020-06-30T14:47:01","guid":{"rendered":"http:\/\/eocanha.org\/blog\/?p=540"},"modified":"2020-06-30T15:47:01","modified_gmt":"2020-06-30T14:47:01","slug":"developing-on-webkitgtk-with-qt-creator-4-12-2","status":"publish","type":"post","link":"https:\/\/eocanha.org\/blog\/2020\/06\/30\/developing-on-webkitgtk-with-qt-creator-4-12-2\/","title":{"rendered":"Developing on WebKitGTK with Qt Creator 4.12.2"},"content":{"rendered":"\n

After the latest migration of WebKitGTK test bots to use the new SDK based on Flatpak<\/a>, the old development environment based on jhbuild became deprecated. It can still be used with export WEBKIT_JHBUILD=1<\/code>, though, but support for this way of working will gradually fade out.<\/p>\n\n\n\n

I used to work on a chroot because I love the advantages of having an isolated and self-contained environment<\/a>, but an issue in the way bubblewrap manages mountpoints<\/a> basically made it impossible to use the new SDK from a chroot. It was time for me to update my development environment to the new ages and have it working in my main Kubuntu 18.04 distro.<\/p>\n\n\n\n

My mail goal was to have a comfortable IDE that follows standard GUI conventions (that is, no emacs nor vim) and has code indexing features that (more or less) work with the WebKit codebase. Qt Creator was providing all that to me in the old chroot environment thanks to some configuration tricks by Alicia<\/a>, so it should be good for the new one.<\/p>\n\n\n\n

I preferred to use the Qt Creator 4.12.2 offline installer for Linux<\/a>, so I can download exactly the same version in the future in case I need it, but other platforms and versions are also available<\/a>.<\/p>\n\n\n\n

The WebKit source code can be downloaded as always using git:<\/p>\n\n\n\n

git clone git.webkit.org\/WebKit.git<\/pre>\n\n\n\n
It’s useful to add WebKit\/Tools\/Scripts<\/code> and WebKit\/Tools\/gtk<\/code> to your PATH, as well as any other custom tools you may have. You can customize your $HOME\/.bashrc<\/code> for that, but I prefer to have an env.sh<\/code> environment script<\/a> to be sourced from the current shell when I want to enter into my development environment (by running webkit<\/a><\/code>). If you’re going to use it too, remember to adjust to your needs the paths used there.<\/p>\n\n\n\n
Even if you have a pretty recent distro, it’s still interesting to have the latests Flatpak tools. Add Alex Larsson’s PPA<\/a> to your apt sources:<\/p>\n\n\n\n
sudo add-apt-repository ppa:alexlarsson\/flatpak<\/pre>\n\n\n\n
In order to ensure that your distro has all the packages that webkit requires and to install the WebKit SDK, you have to run these commands (I omit the full path). Downloading the Flatpak modules will take a while, but at least you won’t need to build everything from scratch. You will need to do this again from time to time, every time the WebKit base dependencies change:<\/p>\n\n\n\n
install-dependencies
update-webkitgtk-libs<\/pre>\n\n\n\n
Now just build WebKit and check that MiniBrowser works:<\/p>\n\n\n\n
build-webkit --gtk\nrun-minibrowser --gtk<\/pre>\n\n\n\n
I have automated the previous steps as go full-rebuild<\/code><\/a> and runtest.sh<\/code><\/a>.<\/p>\n\n\n\n
This build process should have generated a WebKit\/WebKitBuild\/GTK\/Release\/compile_commands.json<\/code>
 file with the right parameters and paths used to build each compilation unit in the project. This file can be leveraged by Qt Creator to get the right include paths and build flags after some preprocessing to translate the paths that make sense from inside Flatpak to paths that make sense from the perspective of your main distro. I wrote compile_commands.sh<\/code><\/a> to take care of those transformations. It can be run manually or automatically when calling go full-rebuild<\/code> or go update<\/code>.<\/p>\n\n\n\n
The WebKit way of managing includes is a bit weird. Most of the cpp files<\/a> include config.h<\/code><\/a> and, only after that, they include the header file<\/a> related to the cpp file. Those header files depend on defines<\/a> declared transitively when including config.h<\/code><\/a>, but that file isn’t directly included by the header file. This breaks the intuitive rule of “headers should include any other header they depend on” and, among other things, completely confuse code indexers. So, in order to give the Qt Creator code indexer a hand, the compile_commands.sh<\/code> script pre-includes WebKit.config<\/code> for every file<\/a> and includes config.h<\/code> from it<\/a>.<\/p>\n\n\n\n
With all the needed pieces in place, it’s time to import the project into Qt Creator. To do that, click File \u2192 Open File or Project<\/em>, and then select the compile_commands.json<\/code> file that compile_commands.sh<\/code> should have generated in the WebKit main directory.<\/p>\n\n\n\n
Now make sure that Qt Creator has the right plugins enabled in Help \u2192 About Plugins…<\/em>. Specifically: GenericProjectManager, ClangCodeModel, ClassView, CppEditor, CppTools, ClangTools, TextEditor and LanguageClient (more on that later).<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
With this setup, after a brief initial indexing time, you will have support for features like Switch header\/source (F4)<\/em>, Follow symbol under cursor (F2)<\/em>, shading of disabled if-endif blocks, auto<\/code> variable type resolving and code outline. There are some oddities of compile_commands.json<\/code> based projects, though. There are no compilation units in that file for header files, so indexing features for them only work sometimes. For instance, you can switch from a method implementation in the cpp file to its declaration in the header file, but not the opposite. Also, you won’t see all the source files under the Projects<\/em> view, only the compilation units, which are often just a bunch of UnifiedSource-*.cpp<\/code> files. That’s why I prefer to use the File System<\/em> view.<\/p>\n\n\n\n
Additional features like Open Type Hierarchy (Ctrl+Shift+T)<\/em> and Find References to Symbol Under Cursor (Ctrl+Shift+U)<\/em> are only available when a Language Client for Language Server Protocol<\/a> is configured. Fortunately, the new WebKit SDK comes with the ccls<\/a> C\/C++\/Objective-C language server included. To configure it, open Tools \u2192 Options… \u2192 Language Client<\/em> and add a new item with the following properties:<\/p>\n\n\n\n