How it works...

When you pass a target recipe to BitBake, it first parses the following configuration files in order:

• conf/bblayers.conf: This file is parsed to find all the configured layers
• conf/layer.conf: This file is parsed on each configured layer
• meta/conf/bitbake.conf: This file is parsed for its own configuration
• conf/local.conf: This file is used for any other configuration the user may have for the current build
• conf/machine/<machine>.conf: This file is the machine configuration; in our case, this is qemuarm.conf
• conf/distro/<distro>.conf: This file is the distribution policy; by default, this is the poky.conf file

There are also some other distribution variants included with Poky:

• • poky-bleeding: Extension to the Poky default distribution that includes the most up-to-date versions of packages
  • poky-lsb: LSB compliance extension to Poky
  • poky-tiny: Oriented to create headless systems with the smallest Linux kernel and BusyBox read-only or RAM-based root filesystems, using the musl C library

And then, BitBake parses the target recipe that has been provided and its dependencies. The outcome is a set of interdependent tasks that BitBake will then execute in order.

A depiction of the BitBake build process is shown in the following diagram: