Building Qt WebEngine Against Other Qt Versions

We have recently gotten the question of how to build and test Qt WebEngine 5.15.3 a lot, so I would like to provide the details and potential problem of a mixed version build here.

This is also relevant for anyone building WebEngine 5.15.x against Qt 5.12.x, another mixed version combination we provide some support for.

First ensure you have all the build dependencies, the dependencies for Linux are listed on Building Qt 5 from Git. For macOS and Windows, it mainly means ensuring a Python2 (yes 2, Chromium still hasn't fully migrated to Python3) and new for Qt 5.15.3, a node.js binary which is now used by Chromium to package certain web interfaces, and which can be downloaded from nodejs.org  or using Homebrew on macOS. Bison and flex is also needed, but should be fairly standard on Mac and Linux and in qt5/gnuwin32 for Windows.

The easiest way build is the same way the developers of Qt WebEngine does it, as part of a full Qt build from sources. You check out all of Qt from qt5.git, checkout 5.15.2 and do a git submodule update --recursive, then enter the qtwebengine module directory, checkout 5.15 (or 5.15.3 once branched) there and do another git submodule update in the qtwebengine directory to get the right src/3rdparty version. You can then configure and build all of Qt as normal from the qt5 root (see Building Qt 5 from Git again).

If you instead already have a Qt5 installation and just want to build Qt WebEngine, you again need the qtwebengine git sources (until 5.15.3 source packages are released), checkout the 5.15 branch as above, and then run the qmake from your installed Qt against the source dir of qtwebengine. You can add any configure options on the qmake command line after a --, for instance:

qmake ../qtwebengine -- -enable-webengine-proprietary-codecs -system-webengine-icu

Once configured you can build and install with make, nmake or jom as usual. Note however the build process will launch a ninja build-system nested, you can override the ninja flags with the environment variable NINJAFLAGS before configuring or append to them with NINJAJOBS after configuring. This is for instance useful if you use icecc, or your machine does not have enough memory to run the default number of ninja threads with the often very memory intensive chromium sources (2-3Gbyte per thread).

That is all you need to do as long as you use qmake, or any build system using pkg-config to find Qt WebEngine, but a thing to watch out for is that if you need to use the newly built Qt WebEngine with cmake projects, is that the qt5 build-system generates slightly wrong cmake files for this mixed versions case. For instance the generated Qt5WebEngineCoreConfig.cmake will contain code like this:

find_package(Qt5${_module_dep}
    5.15.3 ${_Qt5WebEngineCore_FIND_VERSION_EXACT}
    ${_Qt5WebEngineCore_DEPENDENCIES_FIND_QUIET}
    ${_Qt5WebEngineCore_FIND_DEPENDENCIES_REQUIRED}
    PATHS "${CMAKE_CURRENT_LIST_DIR}/.." NO_DEFAULT_PATH
)

This will make cmake look for the Qt dependencies of 5.15.3 versions or newer, which of course doesn't exist if you build against 5.15.2. You either need to modify the generated cmake files for each of the three WebEngine modules to look for 5.15.2 or just 5.15 instead. But the simplest, if you don't mind misleading SO numbers, is editing .qmake.conf in the qtwebengine sources, and changing MODULE_VERSION to 5.15.2, or whatever Qt version you are building against. 

Note Qt WebEngine 5.15.3 is an unusually large update for a point release. The underlying Chromium version has been updated to version 87, as it if was a Qt 5.16, this update has been done for two purposes: a) To keep the version difference as small as possible as we from now on only backport security patches to 5.15, and b) To support running on macOS Rosetta2, which unfortunately didn't have good enough x64 emulation to run Chromium unmodified.  It also mean we appreciate testing even more than usual before the release.