Yocto COMPATIBLE_MACHINE: Match Override Tokens Without Admitting the Wrong Board

A board-specific recipe is skipped for its intended machine, while a loosely related board is accepted after the compatibility expression is broadened. The temptation is to replace the expression with a permissive wildcard. That can make the immediate build proceed while admitting configurations the recipe was meant to reject.

The better diagnostic is to identify the actual override token being matched. Yocto's recipe compatibility check does not simply compare the expression with a board's display name or with one concatenated machine string.

Inspect the token list used by the check

The COMPATIBLE_MACHINE reference says the regular expression is evaluated against MACHINEOVERRIDES. The MACHINEOVERRIDES definition describes a colon-separated list that includes the machine name by default and can include additional machine-family overrides.

Inspect the expanded list for each affected configuration. An illustrative board might contribute soc-demo:board-a, while another contributes soc-demo:board-a-rev2. The common family token can admit both even when the final board tokens differ.

Do not add a family token merely to make a recipe eligible. That token can also activate unrelated overrides elsewhere in the metadata. First determine whether the recipe genuinely supports the family or only a particular board.

Anchor the match when the token must be exact

The examined base class implementation splits MACHINEOVERRIDES on colons and applies re.match to each token. A match on any token satisfies this gate; otherwise the recipe is skipped for incompatibility in the ordinary parsing path.

With the illustrative tokens above, board-a matches the beginning of both board-a and board-a-rev2. If only the first is supported, ^board-a$ states the intended complete-token match. If two exact boards are supported, ^(board-a|board-b)$ groups the alternatives before applying the end boundary.

The Python matching reference explains the start-of-string behavior. Anchors and grouping therefore express compatibility scope, not just stylistic preferences. A pattern that happens to accept today's board list may overmatch a future token with the same prefix.

Diagnose rejection without erasing the restriction

For an unexpectedly skipped recipe, compare the final compatibility expression with every actual machine override token. If none matches, determine which side is wrong: the recipe may name an obsolete token, or the machine configuration may no longer contribute a required family override.

Check assignment history as well. A recipe-specific append or class override can replace the expression that appears in the base recipe. Read the effective value for the same configuration that produced the skip diagnostic.

A broad replacement such as .* is useful only as a carefully bounded experiment when the resulting build is not treated as supported. It does not establish hardware compatibility. Restore a justified gate rather than committing the experiment as the permanent fix.

The documentation also warns against machine-dependent restrictions on native recipes. If the failure occurs in a host-tool variant, inspect that variant's metadata rather than assuming it should inherit the target board's acceptance rule.

Test the acceptance boundary, not only one successful build

Create a small compatibility table for the supported board, a similar-name unsupported board and a different member of any shared family. For each, identify the exact token expected to match or explain why none should match.

Then parse or build the appropriate target in those configurations and compare the outcome with the table. The negative case matters: a successful build for board-a says nothing about whether board-a-rev2 was accidentally admitted by a prefix expression.

Finally, keep compile success separate from runtime qualification. This metadata gate prevents unsuitable recipes from entering a configuration; passing it does not test pin mappings, peripheral availability or target behavior. Once the expression is correct, the product's hardware checks still establish whether the claimed compatibility is real.