A recipe is file (or set of files) which tells Yocto how to build and include a particular application into a image.
Getting Code From Online Git Repositories
Yocto supports the ability to pull code from online git repositories as part of the build process.
What about private repositories? Private repositories have the added complexity of requiring authentication before you can download (a.k.a clone) them. Luckily, Yocto supports the ssh protocol.
To make Yocto use a GitHub repository:
GitLab repositories require a slightly different syntax:
Note the inclusion of
group_name in the above URL (as well as the inclusion of
git:// at the start). This
~/ is important for Yocto to clone the git repo, but is not required (and not included in the GitLab example) when cloning a private GitLab repo normally.
Specifying A Branch
By default, the master branch is used when looking for a particular commit as specified by the
SRCREV hash. However, you can change this default behaviour and specify a particular branch by adding the
branch=<branch-name> option to the
Checking Out Git Submodules
By default, Yocto will not clone submodules when cloning a git repository. This can be a problem for many builds, as usually dependent libraries are added to git repositories as submodules.
Luckily, Yocto provides a way to tell it to check out all git submodules in a recipe. All you have to do is replace the
git:// statement with
A Complete GitHub Example
This is a complete example of a Yocto recipe that downloads and builds the source code from a remote Git repository.
This assumes the CMakeLists.txt contains at least one INSTALL command. bitbake will automatically call cmake, make and make install (if there are no INSTALL commands in the CMakeLists.txt, this part will fail!!!) on the repositories source code.
Recipes need to specify LICENSE and LICENSE_FILES_CHKSUM values. This is so that Yocto can guarantee that certain image builds meet specific licensing requirements (e.g. all applications are open-source and free to re-distribute).
Most source code/binary packages and remote repositories will include a LICENSE file in the root directory. Here is an example snippet from a recipe which points to the license file called LICENSE within the root directory of the repository:
LIC_FILES_CHKSUM is a checksum of a file which includes the license (or, a specific portion of it, e.g. a portion of the README.md). Yocto uses this checksum at build time to make sure the license has not changed, and will produce an error if it has. If the license is an entire file, you can calculate the MD5 checksum by running the following command (in a UNIX system):
The following directory contains license definitions for most common licenses:
This includes BSD, GPL-3.0 and MIT.
Yocto supports patches, which is a way of modifying third-party code before it is included in the build, without first having to duplicate the source code or ask the maintainer to make the change for you.
Patches can be easily created using Git. If you can download the third-party source code as a Git repository, this is definitely the easiest solution. After downloading the repository, make the required changes to the code, and add these changes to the repository as a new commit. You can then tell Git to make a patch file.
If all the changes are contained within a single additional commit, you can use the following command:
These generated patches should be bundled with your recipe files. The patches should always be in a sub-directory of where the recipe lives. The sub-directory name should either be the same name as the recipe, or the name files (I prefer the name files as it seems more intuitive).
The following diagram shows the correct directory structure for both the recipes (.bb file) and the patch(es) (.patch file(s)). We will pretend we are creating a recipe to include gtest (the Google unit test library) in our image.
The last thing you have to do is add a path to your patch in the recipe file.
Yocto will automatically apply these patches when it needs to build your recipe.
This work is licensed under a Creative Commons Attribution 4.0 International License .