At Bootlin we help many of our customers using Yocto/OpenEmbedded to build the Linux software stack running on their end products. While doing that we have seen all sorts of problems caused by all sorts of complicated code in their build system setup. So we wondered what we could do to improve the overall situation.
Part of the problem originates from Bitbake and OE-core providing plenty of tools allowing customization: layers, bbappend files, overrides and more. Such power is of course useful, but can easily be misused by implementing things in incorrect ways which at times create other problems that turn into more incorrect solutions.
Examples of bad Yocto/OE coding we have seen include: abusing local.conf, ignoring warnings, using an old and unsupported Yocto release, using 3rd-party layers that bring more complexity and problems than benefits, using the Poky distro in production, (ab)using AUTOREV and using a git tag or branch name in SRC_URI. But the list could grow way longer.
Learning how to properly use the tools requires experience, which not all end product designers have. As a consequence we have spent a lot of time in educating our customers to clean up their build system and write clean layers. This often involved fixing their problems by removing a lot of the code they had written, or removing lots of meta layers that were bringing more troubles than benefits.
(Image source: Wikimedia, CC BY-SA DEED 2.0)
In reality a layer to support a final product generally does not need to be very complicated, so based on our experiences we implemented simplest-yocto-setup: a simple, but realistic and working, Yocto/OpenEmbedded setup. The goal is to act as an example of how we think the entire build system should look like: easy to understand, efficient, easy to upgrade and less buggy.
simplest-yocto-setup is available at github.com/bootlin/simplest-yocto-setup. It implements what should be typically found in a Yocto setup for end products: two machines, one distro, bootloader and kernel recipes, a user application recipe and an image recipe. All of the above is implemented in less than 350 lines (including the comments we added to clarify the choices made!) and is contained in a single layer which we have called meta-kiss after the “KISS Principle“.
It also has a detailed README.md file describing it and, last but not least, a git history which is also acting as a realistic example of the development process.
This work has been presented in a talk titled “Keep your layer simple — and here’s how” during the Yocto Project Summit 2023.11. You can read the slides on our website and watch the video.
Feel free to use it as an example for your next project, or to grab ideas on how to clean your existing build system! We also offer a Yocto Project training course and can help you in using Yocto in our projects through our engineering services.
Nice article, thanks Luca!
Contrary to most of the Yocto tutorials, you did not start by cloning poky but only picked the useful layers, which I believe is necessary for maintainability.
Is this what you meant by not using the “Poky distro in production” in the “bad practices example” section?
Hello ramacassis,
thanks for appreciating this post!
You got it right, using the Poky distribution in production is considered a bad practice. The Poky distribution is not meant to be used in production but rather as a “demo” working distro configuration that should then be replaced in the early stages of development in order to have the configuration that suits the product needs in the best possible way.
Very likely the fact that many companies end up using the Poky distro in production is partly because many tutorials are based on it, together with the fact that “writing one’s own distro conf” appears to many as one of the most mysterious and daunting tasks in OpenEmbedded development.
Our simplest-yocto-setup is meant to show exactly how a custom defconfig can be written quite easily at least for simple needs, and it also puts your resulting artifacts much more understanding and under your control.
Also don’t forget having no distro at all is also a valid setup, even though just like the Poky distro it is not a good idea for production.
Luca