In a previous post, I built a basic CI pipeline with CTest that uploaded its results to a CDash board. It worked fine except that we had to start the pipeline manually from the command line. In this post, we define a pipeline with GitHub Actions that runs the CI pipeline whenever a developer pushes a code change to a GitHub repository.Read More »A Basic Continuous Integration Pipeline with GitHub Actions
We can use CMake, CTest and CDash to build a basic Continuous Integration (CI) pipeline. The pipeline builds the applications, runs the tests, collects coverage information and uploads all the results to a dashboard on a web server. All this is controlled by one CMake script executed by CTest.Read More »Building a CI Pipeline with CTest and CDash
The Qt version of an embedded Linux system is tied to the Yocto version. Yocto 2.7 (Warrior) comes with Qt 5.12, Yocto 3.1 (Dunfell) with Qt 5.14, Yocto 3.2, 3.3 and 3.4 with Qt 5.15 . There is no Yocto version with Qt 6 yet. How can we build Qt 6.2 against the SDK of old Yocto versions?Read More »Building Qt 6.2 For Old Yocto Versions
CMake uses Graphviz to generate dependency graphs between the targets of a CMake project like libraries and executables. The graphs help us get an idea of the software architecture and identify the dependency hot spots.Read More »Visualising Module Dependencies with CMake and Graphviz
Setting up QtCreator for cross-compilation with CMake took me 15-20 hours the first two or three times. The next half a dozen times took me… Read More »How to Set Up QtCreator for Cross-Compilation with CMake in 5 Minutes
We change the code of our Qt application in QtCreator and press the Run button to try the changes on an embedded device. QtCreator cross-compiles the application, deploys it to the device and runs it on the device. QtCreator performs these steps in a breeze, because we spent quite some time to define a QtCreator Kit. The fairly unknown script configure-qtcreator.sh from the Yocto layer meta-boot2qt automates most of the kit definition.Read More »Cross-Compiling Qt Embedded Applications with QtCreator and CMake
On your development PC, you simply hit Ctrl+R (Run) in QtCreator to build and run your Qt application. When you want to run the application on an embedded system, you must perform four tasks:
- You cross-build the Qt application for the target embedded system in a Docker container.
- You stop the application on the target system.
- You copy the application from the development PC to the target system with
- You start the application on the target system.
Wouldn’t you love to hit Ctrl+R in QtCreator and to have QtCreator perform the above four steps for you? Of course, you would! I’ll show you how in this post. Running an application on an embedded system will be the same as running the application on a PC.Read More »Docker Builds from QtCreator
In my recent post Benefits of a Relocatable Qt, I explained how to relocate Qt from a build server to a developer PC and from the PC to an embedded system. Qt is installed in three different locations. My solution has two small deficiencies. First, it sets the install rpath to an absolute path and restricts the installation to this absolute path. Second, it forces us to create a tarball of the installation directory on the PC manually. Let us fix these two deficiencies.Read More »Creating Simple Installers with CPack
Bob builds Qt for the development team on a fast compute server. He packs Qt into a tarball and hands the tarball to his teammates. Alice installs the Qt tarball on her PC in a directory that differs from the installation directory used by Bob. As the target embedded system runs on an AMD Ryzen SoC with x86_64 architecture like the build server and the development PC, Alice installs Qt on the target system – yet in another directory. She can then try out the latest changes of her app directly on the target system. As Qt is relocatable since version 5.14, Alice’s and Bob’s jobs have become quite a bit easier.Read More »Benefits of a Relocatable Qt