TipsAndTricks/Patching the source for a recipe

From Yocto Project
Jump to: navigation, search

Patching the source for a recipe

One of the useful things about OpenEmbedded building everything from source is that it's fairly easy to make changes to anything that gets built, but doing so for the first time can be a bit daunting.

As part of building a recipe, OE creates a tmp/work/<architecture>/<recipe>/<version> directory, known as the "work directory". This is where all of the work done to build a recipe takes place. One of the things you'll find in this directory is the source, usually under a subdirectory named <recipename>-<version> or "git" (depending on how the fetched source is provided). The temptation (and what people used to do in the past) is to simply make changes here and then recompile, but there are several reasons why that's not a good idea:

  • It's awkward - you have to use bitbake -c compile -f or bitbake -C compile to force recompilation, since the build system doesn't know that you've made any changes
  • You can easily lose your changes if you're not careful e.g. running bitbake -c clean will wipe the directory out

Luckily if you're using the fido (1.8) or later release, there's a much better method using the devtool command:

  1. Run devtool modify <recipename>. This will fetch the sources for the recipe and unpack them to a workspace/sources/<recipename> directory and initialise it as a git repository if it isn't already one. If you prefer you can specify your own path, or if you already have your own existing source tree you can specify the path along with the -n option to use that instead of unpacking a new one.
  2. Make the changes you want to make to the source
  3. Run a build to test your changes - you can just bitbake <recipename> or even build an entire image incorporating the changes assuming a package produced by the recipe is part of an image. There's no need to force anything - the build system will detect changes to the source and recompile as necessary.
  4. If you wish, test your changes on the target. There's a "devtool deploy-target" command which will copy the files installed at do_install over to the target machine assuming it has network access, and any dependencies are already present in the image.
  5. Repeat from step 2 as needed until you're happy with the results.
  6. At this point you will almost certainly want to place your changes in the form of a patch to be applied from the metadata - devtool provides help with this as well. Commit your changes using "git commit" (as many or as few commits as you'd like) and then run either:
    • devtool update-recipe to update the original recipe - usually appropriate if it's your own recipe or you're submitting the changes back to the upstream layer
    • devtool update recipe -a <layerpath> to put your changes in the form of a bbappend to be applied by a different layer. This is usually the desired method if your changes are customisations rather than bugfixes.
  7. If you're finished working on the recipe, run devtool reset <recipename>.

This is just one of the things that devtool can do - it provides some powerful tools to help you maintain recipes and make changes to source code.

Personal tools