Cristian Adam

Speeding up C++ GitHub Actions using ccache

In my previous post Using GitHub Actions with C++ and CMake I have provided a GitHub Actions yaml configuration file for C++ projects using CMake.

Building a project on GitHub Actions means always a build from scratch, for any given change, big or small. This takes time and wastes resources unnecessarily.

GitHub provides a way of caching dependencies to speed up workflows. The total size of cached files per repository is 2 GiB.

By having a look at the examples of various programming languages we can see that this is meant to cache package manager dependencies e.g. pip for python, npn for node, or gradle for java.

But, as it turns out, the caching mechanism can be used to cache compilation artifacts.

Using GitHub Actions with C++ and CMake

In this post I am going to provide a GitHub Actions configuration yaml file for C++ projects using CMake.

GitHub Actions is a CI/CD infrastructure provided by GitHub. GitHub Actions currently offers the following virtual machines (runners):

Virtual environment YAML workflow label
Windows Server 2019 windows-latest
Ubuntu 18.04 ubuntu-latest or ubuntu-18.04
Ubuntu 16.04 ubuntu-16.04
macOS Catalina 10.15 macos-latest

Each virtual machine has the same hardware resources available:

  • 2-core CPU
  • 7 GB of RAM memory
  • 14 GB of SSD disk space

Each job in a workflow can run for up to 6 hours of execution time.

Unfortunately when I enabled GitHub Actions on a C++ project I was presented with this workflow:

./configure
make
make check
make distcheck

This is not something you can use with CMake though smile

Hello World

I am going to build the following C++ hello world program:

#include <iostream>

int main()
{
  std::cout << "Hello world\n";
}

With the following CMake project:

cmake_minimum_required(VERSION 3.16)

project(main)

add_executable(main main.cpp)

install(TARGETS main)

enable_testing()
add_test(NAME main COMMAND main)

TL;DR see the project on GitHub.

Building multiple configurations with CMake in one go!

Coming from other build systems to CMake one will quickly learn that CMake can build only one configuration at a time. In practice you need to set up multiple build directories and configure/build with CMake for each and every one.

Autotools can do static and shared builds of libraries. For CMake most of the project would do a static build, then a shared build by setting the CMake variable BUILD_SHARED_LIBS to ON.

QMake can do debug and release builds at the same time, and as we can read at Qt for Android better than ever before, it can configure multiple Android architecture configurations at the same time.

What can we do to get the same level of convenience with CMake?

Bundling together static libraries with CMake

In this article I’m going to talk about building a C++ library with CMake, but it won’t be a CMake tutorial.

Let’s say you have a C++ library which depends upon a few open source libraries, which have a CMake project structure, but not necessarily done by the book (which means that they get only get built, and not deployed / installed)

Your library will include tests (unit-tests / integration tests), and the deployment can be just packing the headers and the binaries together in a tar.gz file.

This is not necessarily by the book, but it will do the job, and it could fit into any build system that the client has.

A book that one can use to do CMake right is Profesional CMake. Awesome CMake also has a great list of resources regarding CMake.

Coming back to the C++ library, which decisions do we take to build it? Shared library, static library, both?

Speeding up libclang on Windows

In this article I am revisting an article from three years ago: “Speeding up libclang on Windows”, in which I was having a look at how the experimental Clang Code Model was handling a particular source code file.

With the help of Profile Guided Optimization I was able to go down from 10 seconds to 6 seconds.

In the meantime the Clang Code Model has been enabled by default in Qt Creator 4.7.

Three years ago I tested Qt Creator 3.6.0, Qt 5.5.1, LLVM/Clang 3.6.2, MinGW GCC 5.3.0, Visual C++ 2013/5. I tested on a Lenovo W510 Thinkpad with an “Intel(R) Core (TM) i7 CPU M 620 @ 2.67 GHz” CPU.

Now I am going to test Qt Creator 4.8.2, Qt 5.12.2, LLVM/Clang 7.0.1, MinGW GCC 7.3.0, and Visual C++ 2017. I upgraded my laptop to a Lenovo A485 Thinkpad with an “AMD Ryzen 7 Pro 2700U w/ Radeon Vega Mobile Gfx 2.20 GHz” CPU.

How many seconds would it take libclang to parse the file? TL;DR? 3 seconds!

Modifying the default CMake build types

CMake has for single configuration configurators the following build types (configuration):

  • Empty (Qt Creator wrongly refers to this as “Default”)
  • Debug
  • Release
  • RelWithDebInfo – Release with debug information, needed for profiling / post mortem debugging
  • MinSizeRel – Release optimized for size, and not for speed.

If we have a look at CMake’s Modules/Compiler/GNU.cmake we can see:

  # Initial configuration flags.
  string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
  string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
  string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
  string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
  string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")

The empty build type usually contains the common build flags for all build types. It is generated from the CMAKE_C_FLAGS_INIT / CMAKE_CXX_FLAGS_INIT variables, and the CFLAGS / CXXFLAGS system environment variables.

But in the case of an IDE like Qt Creator makes no sense to have, you will end up for GCC with a -O0 (Debug) build. I’ve opened QTCREATORBUG-22013 in this regard.

CMake uses the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variables which will be used to populate the CMAKE_CMAKE_<LANG>_FLAGS_<CONFIG> variables.

There are cases when you might want to change the default build types:

  • Want to have -g1 for RelWithDebInfo, because your binaries are becoming too big
  • Want to improve build times in Debug mode with -gsplit-dwarf
  • Want to link to a different version of the CRT
  • Want to enable all possible warnings from the compiler

Lastly, we want to do all this without putting if clauses in the code, and manually changing the CMAKE_<LANG>_FLAGS variables. The rule of thumb is: if you have to change compiler flags, you should do it in a toolchain file!

A Better QNX CMake Toolchain File

At the end of October 2018 on the Qt development mailing list it was announced that CMake was chosen as the build system (generator) for building Qt6. That also meant that The Qt Company will gradually stop investing in their in house Qbs build system.

I personally think is a good idea to have major C++ projects like Boost (July 2017 switch announcement! ), LLVM/Clang, and now Qt to use CMake as their build system (generator). We C++ developers should work together in having a common build system.

There was a bit of email traffic on this topic. There was some skepticism of CMake being able to support specialized operating systems like QNX, so I pointed to an October 2017 blog entry of Doug Schaefer named QNX CMake Toolchain File. There Doug Schaefer presents us with a minimal CMake Toolchain File.

Since I am lucky(sweat_smile) to have a QNX 7.0 license I tried to compile and run the recently released CMake 3.13.0 for the QNX 7.0 x86_64 target!

Speeding up CMake

At the beginning of this year Bits’n’Bites wrote an article named Faster C++ builds, in which it’s being described how you can accelerate building LLVM using ninja, using a cache etc.

The following excerpt caught my eye:

For most developers, the time it takes to run CMake is not really an issue since you do it very seldom. However, you should be aware that for CI build slaves in particular, CMake can be a real bottleneck.

For instance, when doing a clean re-build of LLVM with a warm CCache, CMake takes roughly 50% of the total build time!

So I decided to build LLVM 4.0.0 (and clang) on my 2011 Core i7 Lenovo W510 laptop and see if I can reproduce his findings.

Qt Creator, Ubuntu, and VirtualBox

It is common for IT companies (at least in Germany, automotive field) to use Ubuntu Linux LTS in a VirtualBox on Windows or Mac hosts. This way the employee can use Microsoft Outlook / Office, Microsoft Skype, Cisco Spark, or other proprietary collaboration tools, and at the same time use the supplied virtual machine for development.

By default VirtualBox doesn’t configure any 3D acceleration or multi-core CPU for the guest. One needs to change these settings in order to have a more responsive desktop environment and to compile faster smile Also important not to forget about the installation of the VirtualBox Guest Additions.

Running glxinfo on a Ubuntu Linux 16.04 LTS in VirtualBox 5.1.18 gives back this information:

OpenGL vendor string: Humper
OpenGL renderer string: Chromium
OpenGL version string: 2.1 Chromium 1.9
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

As it turns out this is not enough to run Qt Creator 4.2.1. Qt Creator simply displays a black welcome screen on Ubuntu Linux 16.04 LTS, or simply crash on Ubuntu 14.04 / 12.04 LTS:

If Qt Creator is run from command line, it will give out these messages (Ubuntu 16.04 LTS):

QOpenGLFramebufferObject: Unsupported framebuffer format.
QOpenGLFramebufferObject: Unsupported framebuffer format.

If you do a web search after “Qt Creator VirtualBox crash” you will find out how to fix this problem – either disabling the welcome plug-in, or disable the 3D acceleration of your VirtualBox.

Disabling the 3D acceleration means that the system will use a software OpenGL driver.

But then again why not simply use a software OpenGL driver just for Qt Creator and not for the whole system?

NullPointerException in C++

For those familiar with languages like Java, and C#, something like NullPointerException shouldn’t come as a surprise. But what about C++? C++ also has exceptions, right?

In C++ reading or writing at address zero is an access violation. By default an access violation will result in the immediate termination of the program. What else results in immediate termination of the program? Division by zero! There is no ArithmeticException, only a swift termination!

The OS’ SDK usually provides a way to catch such access violations and recover from them. This way of catching access violations involves a C callback method and a bit of setup.

Wouldn’t be nice if the setup would be one line of code and the C callback function would throw C++ exceptions behind the scenes?

But it does work like this. At least on Windows and Linux (I don’t have access to a macOS machine), and only with a few select compilers.

Before going further into details I would like to present my test case: define functions which do:

  • Division by zero
  • Reading from nullptr
  • Writing at nullptr
  • Write to an empy vector with the subscript operator []
  • Read from an uninitialized shared_ptr

Execute them ten times to make sure that this is not only one time “wonder”. Every try block will have an instance of a RAII Message object to make sure that stack unwinding is taking place, and that we won’t have any resource leaks.