Fix/ninja object path missing - #79
Open
prakhar7017 wants to merge 2 commits into
Open
Conversation
## Problem
`ebuild/build/dispatch.py` does not parse. `BackendDispatcher.configure()`
carries two `else:` clauses attached to the same `if` chain:
File "ebuild/build/dispatch.py", line 133
else:
^^^^
SyntaxError: invalid syntax
Every `ebuild` command that reaches the dispatcher imports this module, so
on master `ebuild build`, `ebuild configure` and `ebuild clean` all fail at
import, and pytest aborts collection with 2 errors before running anything.
The cause is a merge, not a typo. Two branches independently added an
unhandled-backend guard to `configure()` — one raising `ValueError` listing
`ALL_BACKENDS`, one raising `RuntimeError` with a ninja-specific hint. The
merge kept both bodies. Their two test suites survived as well and disagree:
`tests/ebuild/test_dispatch.py` expects `ValueError`, `tests/unit/test_dispatch.py`
expects `RuntimeError`.
Two further defects were preserved in the same chain:
- `configure()` listed `ninja` alongside make/kbuild as a silent no-op.
`ebuild build` routes `backend: ninja` with no `targets` into the
dispatcher (`commands.py`: `if resolved_backend != "ninja" or not
cfg.targets`), which has no ninja configure step. Returning quietly there
is the exact false-success the `RuntimeError` guard was written to stop.
- The `ValueError` message advertised `ALL_BACKENDS`, which contains
`ninja`, so rejecting `ninja` produced a message naming `ninja` as
supported.
## Fix
- Remove the duplicated `else:` and consolidate the two guards into one.
- Add `UnknownBackendError(ValueError, RuntimeError)`. Deriving from both
keeps each pre-existing caller contract intact rather than silently
dropping one, and it is load-bearing beyond the tests: `ebuild build`
handles this through `except RuntimeError`, so a plain `ValueError` would
reach the user as a traceback instead of a clean `exit 1`.
- Name the backends each step actually handles (`CONFIGURE_BACKENDS`,
`BUILD_BACKENDS`, `CLEAN_BACKENDS`) and report those in the message, so it
can no longer contradict the rejection. `clean` keeps `ninja`; it only
removes a build directory and needs no toolchain.
- Drop `ninja` from the `configure()` no-op branch so it raises, carrying the
actionable "requires 'targets' in build.yaml" hint.
Behaviour change: `BackendDispatcher.configure("ninja")` previously returned
None and now raises. Nothing in-tree relies on the old behaviour — the CLI
`configure` command routes ninja to `_configure_ninja_backend` before the
dispatcher is constructed.
## Testing
- `pytest tests/ebuild/test_dispatch.py tests/unit/test_dispatch.py` —
31 passed. Both previously-conflicting suites pass unmodified.
- Full suite: 196 passed, 1 skipped, 11 failed. All 11 failures are
pre-existing and unrelated (`_object_path` missing from `NinjaBackend`,
initramfs integration, build-failure output); they were present before
this change and are unaffected by it.
- End-to-end, a `build.yaml` with `backend: ninja` and no `targets`:
[error] Unknown build backend 'ninja'. BackendDispatcher can
configure: cargo, cmake, kbuild, make, meson. ebuild's own ninja
backend is invoked directly rather than through BackendDispatcher,
and requires 'targets' in build.yaml -- add targets or choose
another backend.
EXIT=1
Clean message, correct exit code, no traceback.
- Six regression tests added covering the dual-inheritance contract, the
ninja rejection, the actionable hint, the non-contradictory backend list,
`clean("ninja")` still working, and cargo/make/kbuild remaining no-ops.
Signed-off-by: Prakhar Maheshwari <mpr@stordocktech.com>
Signed-off-by: Prakhar Maheshwari <prakharmaheshwari96@gmail.com>
## Problem
`NinjaBackend.generate()` cannot produce a build. Both writers call
`self._object_path(...)`, but the method does not exist:
ebuild/build/ninja_backend.py:143: in _write_ninja
obj = str(self._object_path(target, src))
AttributeError: 'NinjaBackend' object has no attribute '_object_path'
This is ebuild's own backend -- the path `ebuild build` takes for any
`build.yaml` that declares `targets`. It is unusable, and 5 tests fail on it
purely incidentally, none of which is actually about object paths.
`_object_path()` and its 137 lines of tests were added by 9cb7c89
("give each target its own object files"). Merge 5ef3a61 kept both call sites
but dropped the method, and replaced `tests/unit/test_ninja_backend.py`
wholesale, taking the regression tests with it. With no test left asserting
the behaviour, nothing caught the loss -- it surfaced only as an
`AttributeError` in unrelated tests.
## Fix
Restore `_object_path()` verbatim from 9cb7c89. Objects are named
`obj/<target>/<source>.o` rather than from the source alone.
Sharing a source between targets is ordinary -- a library and a test binary
using one helper, or one source built twice with different defines. Naming the
object from the source alone makes both targets claim the same output, which
ninja rejects outright, and silently drops one target's cflags before it gets
that far. Objects under `obj/<target>/` match what CMake, Meson and Bazel do
for the same reason. Target output names are unchanged, so nothing downstream
moves.
## Testing
Restored the three dropped regression tests as `TestObjectPathNamespacing` in
`tests/unit/test_ninja_backend.py`, adapted to that file's current layout:
- `test_shared_source_gets_one_object_per_target` -- a source used by two
targets yields two distinct compile edges, and both targets' defines survive.
- `test_shared_source_manifest_is_valid_ninja` -- runs real `ninja -n` against
the generated manifest. Looking right is not the same as loading.
- `test_compile_commands_distinguishes_shared_source_entries` -- the two
compilation-database entries for a shared source name different objects.
The third was strengthened over the original: it asserted only that the two
command strings differ, which held even with the bug present, because the two
targets carry different `-D` flags. It now compares the `-o` paths, the
property a consumer actually keys on.
Verified the tests detect the bug rather than merely passing. With the
pre-9cb7c89 source-keyed naming reinstated, all three fail, and real ninja
gives the original error:
ninja: error: _build\build.ninja:34: multiple rules generate _build/src/util.o
With the fix: 3 passed.
Full suite: 205 passed, 6 failed (was 11 failed before this change). All 6
remaining failures are pre-existing and unrelated to object paths.
Note: `ninja>=1.11` is a declared dependency but was absent from the
environment, so ninja-dependent tests had been silently skipping. Installing it
unmasked a further pre-existing defect -- generated paths are not escaped, so a
build directory containing a space produces an invalid manifest
("expected build command name"). Confirmed independent of this change by
reproducing it with the old object naming in place. It will be sent separately.
Signed-off-by: Prakhar Maheshwari <mpr@stordocktech.com>
Signed-off-by: Prakhar Maheshwari <prakharmaheshwari96@gmail.com>
prakhar7017
requested review from
hshanmug12,
maheshmunnangi and
srpatcha
as code owners
August 30, 2026 12:24
srpatcha
reviewed
Aug 30, 2026
srpatcha
left a comment
srpatcha
left a comment
Member
There was a problem hiding this comment.
Thanks for this — the diagnosis is right, but the fix has already landed by
another route, so I want to save you the rebase.
This restores NinjaBackend._object_path(), which a cflags merge had deleted. #66 restores it too, with target-namespaced object paths and the same worked example:
>>> backend._object_path(target, "src/main.c") # target.name == "app"
PosixPath('_build/obj/app/src/main.o')and the same reasoning — two targets may legitimately list one source (a library
and a test binary sharing a helper, or one source built twice with different
defines), so keying only on the source made both claim one output and ninja
rejected it with "multiple rules generate ...".
Where that leaves this PR
It also touches dispatch.py, which conflicts with #66 — already approved, and
the PR that repairs master's SyntaxError (#87). Verified: this branch does not
apply cleanly on top of it.
Rather than resolving the conflict, I would close this. Nothing in it is wrong;
it is second to arrive at the same place.
If part of this does something #66 and 49cd368 do not, say which and I will
look again — I compared the object-path namespacing and the escaping semantics,
not every line.
Something open, if you want it
#85 — eos and eBoot both define CMake targets named test_crypto and
test_multicore, and since ebuild composes them with add_subdirectory, the
integration build cannot configure at all. Same class of bug as the ones you have
been finding, one repository wider.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix a syntax error in
ebuild/build/dispatch.pycaused by duplicateelse:clauses inBackendDispatcher.configure().Problem
NinjaBackend.generate()cannot produce a build. Both writers callself._object_path(...), but the method does not exist:The merge conflict left two different unknown-backend guards in the same
ifchain, causingebuild build,ebuild configure, andebuild cleanto fail during import.Changes
else:and consolidated the backend validation logic.UnknownBackendError, inheriting from bothValueErrorandRuntimeError, to preserve the existing caller contracts.CONFIGURE_BACKENDSBUILD_BACKENDSCLEAN_BACKENDSninjafrom the configure no-op path so unsupportedninjaconfiguration fails with an actionable error.ninjasupported forclean, where no toolchain is required.ValueError/RuntimeErrorinheritanceninjarejection during configureclean("ninja")continuing to workcargo,make, andkbuildno-op behaviorTesting
Targeted tests