We can build the Qt versions from 6.2 to 6.5 with the meta-qt6 layer for the Yocto versions 3.1 to 4.1. This is a big time saver.
| Yocto \ Qt | 6.5 | 6.4 | 6.3 | 6.2 |
|---|---|---|---|---|
| 4.2 (Mickledore) | T | T | – | – |
| 4.1 (Langdale) | T | T | C | C |
| 4.0-LTS (Kirkstone) | T | T | T | T |
| 3.4 (Honister) | C | C | T | T |
| 3.3 (Hardknott) | C | C | C | C |
| 3.2 (Gatesgarth) | C | C | C | C |
| 3.1-LTS (Dunfell) | T | T | T | T |
(T = tested, C = compatible, – = not supported)
“T” means that the Qt version is tested on the Yocto version. “C” means that the Qt version can be built with the Yocto version. “-” means that the Qt version does not build on the Yocto version. Qt 6.0 and 6.1 are missing from the table, because they lacked some features from Qt 5.
The choice of the SoC, SoM or terminal determines the Yocto version of the BSP. For Qt 5, the Yocto version determined the Qt version through the recipes in meta-qt5. For example, Yocto 2.7 (Warrior) is bound to Qt 5.12 and Yocto 3.1 (Dunfell) to Qt 5.14. If we wanted to move to a newer Qt 5 version, we had to update some recipes ourselves. If we wanted to move to a Qt 6 version, our best option was to build Qt 6 against the SDK created by Yocto. That’s considerable extra work.
The developers of the meta-qt6 layer save us this extra work. They provide recipes for newer Qt 6 versions in older Yocto versions. If, for example, we want to build Qt 6.5 for Yocto 3.1, we must only select the right git reference in the repo manifest file or in the kas configuration file. A big thank-you to the meta-qt6 developers 🙏🙏🙏