In a webinar organised by The Qt Company on 8 July 2020, I showed how QtCreator builds an embedded application against a Qt SDK encapsulated in a Docker container. QtCreator doesn’t know which Yocto version was used for building the Qt SDK and which environment variables must be set for the SDK. QtCreator forwards the CMake calls for configuring, building and staging the application to the container, which executes these calls in the right environment.
You find the video of the webinar here. My part starts at 2:30 minutes. Here are the slides from my talk.
The webinar is based on my post Docker Builds from QtCreator, which is also published on the official Qt blog. In these identical posts, the target device runs Ubuntu 18.04 on an AMD Ryzen processor with x86_64 architecture. My build workstation, which doubles up as my development computer, runs Ubuntu 16.04.
For some readers, the “obvious” solution was to build Qt and the application on Ubuntu 16.04 and copy both to the target device – with scp. Alternatively, some readers suggested that I build the application in a Ubuntu 18.04 virtual machine. Both approaches would work. But they miss the point I was trying to make.
Builds from QtCreator should not know, which processor architecture the targte device uses, with which Yocto version the target system was built and on which Ubuntu version the Docker container was based. The Docker container hides all these details from QtCreator.
In the webinar, I use a Raspberry Pi for the target device. This move excludes the “obvious” approaches and forces us to build and install a Qt SDK. My idea of forwarding QtCreator’s CMake calls to the container still works – no matter whether the target device runs on an AMD Ryzen, Raspberry Pi, i.MX8, i.MX6 or any other SoC.
Slides 2-5 describe the problem and discuss the pros and cons of three possible solutions: virtual machines, containers on a local workstation and containers on remote workstations. I hope these slides and my explanations in the video give a clear motivation for my approach. If not, feel free to comment below.
Thanks for sharing Your hard work.
Have You considered spanning the QtCreator from withing the docker itself.
From my perspective the only drawback would be that You probably eventually end working with different version of QtCreator (which is not the end of the world for me :).
The positive side, You do not have to setup (and worry about) all this environment.
Starting QtCreator from inside the Docker container was my very first idea. Some parts of QtCreator were black, some were unresponsive.
The reason for these problems was most likely the graphics card (Nvidia for me), which was not shared properly between my host PC and the Docker container. Following the Web’s advice, I installed the latest graphics drivers, which crashed my Linux workstation.
I simply couldn’t get this solution working. Installing specific graphics drivers ties the solution to a specific workstation setup. It might work for Solution 2: Containers on a local workstation. My goal is, however, Solution 3: Containers on remote workstations. Solution 3 works on headless build servers – no need to install any graphics drivers.
I want teams to be able to use a fast build server somewhere in the network for cross-building their applications – like they do for building Linux images and SDKs. By the way, CLion supports this already.