Bitbake offers many ways to adjust the behavior of a recipe present in some layer (e.g. meta-libraries) in other layers (e.g. meta-apps). For example, there are OVERRIDES or bbappend files. For source files, adding patches is easy to do.

I often have the situation that I store a configuration file for a recipe inside bitbake repositories. It's normally located next to the corresponding recipe's .bb file, e.g. in "${THISDIR}/files:". Different machines or layers need different config options, so I override the whole file in a machine layer or via machine overrides. However, config files often have some defaults set in the recipe, some special values set for a machine and some other special values set in a meta layer. AFAIK, it's only possible to override a whole file.

Thus, there are often many copies of the config file, similar to this example:

├── meta-apps
│   └── recipes-core
│       └── some-lib
│           ├── files
│           │   ├── machineA
│           │   │   └── some-sane-defaults.conf
│           │   ├── machineB
│           │   │   └── some-sane-defaults.conf
│           │   └── some-sane-defaults.conf
│           └── some-lib.bbappend
└── meta-libraries
    └── recipes-core
        └── some-lib
            ├── files
            │   ├── machineA
            │   │   └── some-sane-defaults.conf
            │   ├── machineB
            │   │   └── some-sane-defaults.conf
            │   └── some-sane-defaults.conf
            └── some-lib.bb

Where the config (e.g. some-sane-defaults.conf) contains:

• some-lib.bb has config options sane for everyone

timeout = 43

• machineA should add something, e.g. its name

timeout = 43
name = A-Team

• some-lib.bbappend in meta-apps needs, say, a GUI option:

timeout = 43
gui = true

• So if I want an app on machineA the config becomes:

timeout = 43
name = A-Team
gui = true

This is a lot of copy paste. Say, I discover a better default value: timeout = 42. Now it's necessary to change each and every config file. Also, if the files grow bigger it's harder to see, which config options are needed because of which machine or layer. Hence, it would be best, if each config file only contained the changes specific to it:

• some-lib.bb:

timeout = 42

• machineA folder in meta-libraries:

name = A-Team

• some-lib.bbappend in meta-apps:

gui = true

• So if I want an app on machineA, there isn't even the need for a config, because it's all handled by bbappends and overrides.

Solutions from other areas

For source files (in ${S}) bitbake offers a convenient patching mechanism via do_patch task. But the configs are not located in the source directory.

For the Linux kernel there are config fragments to solve this. But I can't influence the format of all my config files, e.g. because some are from open source projects.

I assume adjusting config files is rather common in a bitbake/yocto setup and it's a very powerful and complex tool: does it offer a similar mechanism for my situation?