Repository navigation
Fix/ninja object path missing - #79
Conversation
## 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>
srpatcha
left a comment
srpatcha
left a comment
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.
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