The content-hash cache covered recipe-level PKGARs and the recipe's own
source tree, but not Cargo 'path =' dependency sources inside a crate —
the exact pattern the local fork model mandates (redox_syscall, libredox,
redox-driver-*, pcid_interface). Editing a path-dep's source left the
dependent recipe cached and stale. Observed live during the
driver-manager QEMU gate: 'cook driver-manager - cached' while
redox-driver-core sources had changed; the markers never reached the ISO.
Fix:
- New cook::cargo_path_deps module: resolves path deps from Cargo.toml
([dependencies], dev/build deps, target-specific deps, [patch.*]
tables, workspace members) recursively with cycle protection, and
hashes each resolved source tree (sorted relpath+content walk,
excluding .git/target — same policy as SourceContentHash).
- DepHashes gains a cargo_path_deps table (serde default for backward
compatibility; a missing field invalidates once, then re-syncs).
- The rebuild decision now ORs recipe-PKGAR changes with cargo path-dep
tree changes; the post-build write records the new map.
Acceptance: cook -> cached; content edit in redox-driver-core ->
'DEBUG: cargo path-dep source hashes changed' + rebuild; revert ->
rebuild once -> cached. 48 tests pass (43 cookbook lib + 5 new).
vasilito
6ce94d1c9e