fix: prevent false success for unsupported system backend

[muhammadburhandevv-hub]

Summary

Fixes an issue where eBuild could report a successful build even though no
supported build backend ran. A system: section is now kept separate from
backend configuration, and unsupported backends fail with a clear error.

Type of Change

• feat — New feature
• fix — Bug fix
• docs — Documentation only
• style — Formatting, no code change
• refactor — Code restructuring without behavior change
• test — Add or fix tests
• build — Build system or dependency changes
• ci — CI/CD pipeline changes
• perf — Performance improvement

Changes

• Keep system: settings separate from compilation backend configuration.
• Preserve explicit backend selection and normal backend auto-detection.
• Raise BackendError when the external dispatcher cannot handle a backend.
• Add configuration, dispatcher, and CLI regression tests.
• Reconcile the fix with the latest upstream dispatcher changes.

Testing

• Unit tests pass (ctest --test-dir build --output-on-failure)
• Integration tests pass
• Manual testing performed
• New tests added for new functionality

Focused Python regression tests:

47 passed

Additional validation:

• Python compilation passed.
• git diff --check passed.
• Full pytest suite: 198 passed, 11 failed, 1 skipped.

Pre-Submission Checklist

• Code compiles without warnings (-Wall -Wextra -Werror for C)
• All existing tests pass
• New tests added for new functionality
• Documentation updated if API changed
• Commit messages follow <type>(<scope>): <description> convention
• Branch is rebased on latest master

Related Issues

No related issue number.

Screenshots / Logs

============================= 47 passed in 0.33s =============================

Additional Notes

• This change does not implement a new system compilation backend.
• The CTest command was not run because this contribution changes the Python
  eBuild implementation and its pytest suite.
• The full pytest failures are outside this change. Three require cpio, which
  is unavailable in the Windows test environment. The remaining failures come
  from an existing missing NinjaBackend._object_path method.

[srpatcha]

Same defect as #66, reached from a different direction — needs a rebase

The problem you are fixing is real and it is the same one #66 addresses: BackendDispatcher accepting a backend it does not implement and letting the caller report "Build completed successfully" when nothing ran.

Both PRs edit ebuild/build/dispatch.py and they conflict with each other. #66 is further along — it also repairs three defects that stop master running at all:

$ ebuild new hi && cd hi && ebuild build
  File ".../ebuild/build/dispatch.py", line 133
    else:
    ^^^^
SyntaxError: invalid syntax

$ pytest
2 errors during collection

So I have approved #66 to land first. Verified locally: this branch on current master is 9 failed / 201 passed, and it conflicts with #66 in dispatch.py.

What is yours alone, and worth keeping

Two things in here are not in #66, and I would not want them lost in the rebase:

• Keeping system: separate from backend configuration in ebuild/core/config.py. fix: restore the package import and reconcile the merged backend behaviour #66 does not touch this. A system: section being read as backend config is how the false-success path gets entered in the first place, so this is arguably the more upstream fix of the two.
• tests/ebuild/test_build_cli.py — a CLI-level regression test. fix: restore the package import and reconcile the merged backend behaviour #66's coverage is at the dispatcher; asserting it at the command boundary is what catches a future reintroduction through a different route.

Suggested rebase

Once #66 lands, drop your dispatch.py hunks in favour of its version — it raises RuntimeError from configure(), build() and clean() uniformly, and removes "ninja" from the list of backends that need no configure step, which is the specific hole that let configure("ninja") succeed silently. Then keep the core/config.py change and the CLI test on top. That should be a small branch and I will merge it.

One question worth settling while you are in there: #66 standardised on RuntimeError and this PR raises BackendError. A dedicated exception type is arguably better, but the tree currently has two test files that already disagree about which type to expect, so whichever wins should win everywhere rather than adding a third. If you would rather introduce BackendError properly, that is fine by me — just make configure, build and clean all raise it and update both tests/ebuild/test_dispatch.py and tests/unit/test_dispatch.py.

[srpatcha]

Approving for the config.py half, which is a real bug nobody else has covered.

The unique and valuable part

System-image settings are not a compilation backend. Keep them separate.

That is exactly right, and I verified the failure. config.py:230 sets

if raw.get("system") and isinstance(raw["system"], dict):
    backend_config.update(raw["system"])
    if backend == "auto":
        backend = "system"

but "system" is not a backend:

ALL_BACKENDS = {"cmake", "make", "meson", "cargo", "kbuild", "ninja"}

So a build.yaml with a perfectly valid system: section selects a backend the
dispatcher has never heard of. Before #66 that fell through silently — the false
success in your title. With #66 merged it now fails, which is better, but with a
message that blames the user's own valid configuration:

$ ebuild build          # build.yaml has a system: section
[error] Unknown build backend 'system'. Supported backends: cargo, cmake,
        kbuild, make, meson.
exit=1

ebuild system exists as a command, so system-image builds are a supported
feature being reported as an unknown backend. Your split — keeping
system_config out of backend selection entirely, with 'system' must be a mapping validation and a None guard — fixes the cause rather than the
symptom. Neither #66 nor any other open PR touches this.

The dispatch.py half overlaps #66

BackendError(RuntimeError) here and UnknownBackendError(ValueError, RuntimeError) in #66 solve the same problem. #66's inherits from both
deliberately, because the two existing test suites disagreed about which
exception to expect:

tests/ebuild expects ValueError("Unknown build backend '<name>'") while
tests/unit expects RuntimeError matching "ninja". Both are legitimate
readings.

BackendError(RuntimeError) alone would fail the tests/ebuild expectation. #66
is also already approved and carries the master syntax repair (#87), so it
lands first either way.

Suggested path

Rebase onto #66 and drop the dispatch.py and tests/ebuild/test_dispatch.py
hunks, keeping config.py, tests/ebuild/test_config_validation.py and
tests/ebuild/test_build_cli.py. This then reviews cleanly on its own merits and
the part that is uniquely yours is not stuck behind a conflict.

Approving now so it is not blocked on me, but it does need that rebase before it
can merge.

[muhammadburhandevv-hub]

Hi EmbeddedOS Team, I’ve addressed the review feedback and updated the eBuild PR (#65). With all three PRs rebased and ready (eBoot #57, eOS #74, and eBuild #65), I’d love to check in on the next steps in the evaluation process. Could we schedule a short call to discuss the role and next steps? Please let me know what day and time work best for your team. Best, Muhammad

…

On Mon, 31 Aug 2026 at 02:15, Srikanth Patchava ***@***.***> wrote: ***@***.**** approved this pull request. Approving for the config.py half, which is a real bug nobody else has covered. The unique and valuable part System-image settings are not a compilation backend. Keep them separate. That is exactly right, and I verified the failure. config.py:230 sets if raw.get("system") and isinstance(raw["system"], dict): backend_config.update(raw["system"]) if backend == "auto": backend = "system" but "system" is not a backend: ALL_BACKENDS = {"cmake", "make", "meson", "cargo", "kbuild", "ninja"} So a build.yaml with a perfectly valid system: section selects a backend the dispatcher has never heard of. Before #66 <#66> that fell through silently — the false success in your title. With #66 <#66> merged it now fails, which is better, but with a message that blames the user's own valid configuration: $ ebuild build # build.yaml has a system: section [error] Unknown build backend 'system'. Supported backends: cargo, cmake, kbuild, make, meson. exit=1 ebuild system exists as a command, so system-image builds are a supported feature being reported as an unknown backend. Your split — keeping system_config out of backend selection entirely, with 'system' must be a mapping validation and a None guard — fixes the cause rather than the symptom. Neither #66 <#66> nor any other open PR touches this. The dispatch.py half overlaps #66 <#66> BackendError(RuntimeError) here and UnknownBackendError(ValueError, RuntimeError) in #66 <#66> solve the same problem. #66 <#66>'s inherits from *both* deliberately, because the two existing test suites disagreed about which exception to expect: tests/ebuild expects ValueError("Unknown build backend '<name>'") while tests/unit expects RuntimeError matching "ninja". Both are legitimate readings. BackendError(RuntimeError) alone would fail the tests/ebuild expectation. #66 <#66> is also already approved and carries the master syntax repair (#87 <#87>), so it lands first either way. Suggested path Rebase onto #66 <#66> and drop the dispatch.py and tests/ebuild/test_dispatch.py hunks, keeping config.py, tests/ebuild/test_config_validation.py and tests/ebuild/test_build_cli.py. This then reviews cleanly on its own merits and the part that is uniquely yours is not stuck behind a conflict. Approving now so it is not blocked on me, but it does need that rebase before it can merge. — Reply to this email directly, view it on GitHub <#65?email_source=notifications&email_token=CF4LHR5YGDAIUAGGSAPQJJT5MSKODA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMBWGE4TCMJZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5061911950>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CF4LHRYGPPN5NN7BTI4WTLT5MSKODAVCNFSNUABGKJSXA33TNF2G64TZHMYTCOJQGEZDKNZYGE5US43TOVSTWNJSG43TQMJWGUZTJILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CF4LHR6UOO6W5KKTZKOAYRD5MSKODA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMBWGE4TCMJZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CF4LHR3LTFGEOL4GAAXACUD5MSKODA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMBWGE4TCMJZGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>