In the previous article, we understood what BitBake is and how it drives the entire build process.
Now comes the real control layer:
👉 Configuration
Because in Yocto, you don’t “write commands” to control the build…
👉 You configure the system.
And BitBake executes based on that configuration.
Where Does Configuration Live?
When you initialize a build environment, BitBake creates a build directory with a conf/ folder.
Inside this folder, you’ll typically see:
local.confbblayers.conf
These are the two most important configuration files.
👉 BitBake reads these files first to understand what to build and how to build it
1. bblayers.conf — What to Include in the Build
This file answers:
👉 Which layers should BitBake consider?
It contains a key variable:
BBLAYERS
This variable lists:
- Paths to metadata layers
- The building blocks of your system
👉 BitBake uses this to locate recipes, classes, and configs
Why This Matters
If a layer is not listed here:
❌ BitBake will not see it
❌ Its recipes won’t be available
👉 No layer = No functionality
2. local.conf — How to Build
If bblayers.conf defines what is available…
👉 local.conf defines how the build behaves
It is used for:
- Machine selection
- Image configuration
- Build tuning
Common Things You Control Here
- Target hardware
- Number of threads
- Packages to include
- Build output behavior
👉 It acts as the central customization point for your build
3. Other Configuration Files (Less Talked About, Still Important)
Apart from the main two, BitBake also supports:
site.conf→ Shared configuration across buildsauto.conf→ Typically used by automation systems
👉 These are included internally during configuration parsing
How BitBake Processes Configuration
Here’s what happens internally:
- Reads
bblayers.conf - Loads layer configurations (
layer.conf) - Parses global configuration (
bitbake.conf) - Includes
local.conf,site.conf, etc.
👉 All of this builds a data store of variables used during execution
Important BitBake Variables You Must Know
Now let’s focus on the variables that actually control your build.
1. MACHINE
Defines the target hardware.
👉 Example:
MACHINE = "qemux86"
This controls:
- Kernel
- BSP
- Hardware-specific configurations
2. BBLAYERS
Defined in bblayers.conf.
👉 Tells BitBake where to find metadata.
Without this, nothing works.
3. IMAGE_INSTALL
Controls:
👉 What goes into your final image
Example:
IMAGE_INSTALL += "nano"
4. DL_DIR
Defines:
👉 Where downloaded source code is stored
Helps in:
- Reusing downloads
- Faster builds
5. SSTATE_DIR
Controls:
👉 Shared state cache location
👉 This is critical for:
- Incremental builds
- Faster rebuilds
6. BB_NUMBER_THREADS
Controls:
👉 Parallel execution
Example:
BB_NUMBER_THREADS = "8"
7. PARALLEL_MAKE
Controls:
👉 Parallel compilation
Example:
PARALLEL_MAKE = "-j8"
The Real Insight Most People Miss
Beginners often think:
👉 “I need to write recipes to control behavior”
But in reality:
👉 Most build customization starts with configuration variables
Small Change, Big Impact
Changing just one variable can:
- Switch hardware
- Add/remove packages
- Change performance
- Modify output completely
👉 That’s the power of BitBake configuration
Common Beginner Mistakes
- Editing recipes instead of configuration
- Not understanding layer inclusion
- Ignoring variable overrides
- Putting everything in
local.conf
Connecting Everything Together
Here’s the simplified flow:
👉 bblayers.conf → Defines available layers
👉 local.conf → Defines build behavior
👉 Variables → Control execution
👉 BitBake → Executes based on all of this
What’s Next in This Series?
Now that you understand how to control the build…
In the next article, we’ll make things practical:
👉 Creating your first Hello World BitBake recipe
We’ll cover:
- Writing a simple
.bbfile - Understanding basic tasks
- Running your first custom build
- Seeing how everything you learned comes together
This is where things start becoming real.
Want to Learn This Hands-On?
If you want to go beyond theory and actually build confidence with Yocto: