fix(pipeline): absolutize project_dir to fix relative-path include doubling#315
Conversation
|
Warning Review limit reached
More reviews will be available in 53 minutes and 17 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
) `fbuild test-emu .build/pio/<env>` was failing every ESP32 QEMU CI run with `fatal error: FastLED.h: No such file or directory` even though the preceding `ci-compile.py` step had just produced a working firmware in the same directory. Root cause: the CLI passes the project path through verbatim. ci-compile.py sends an *absolute* path (workspace-rooted) so include flags end up absolute, get stripped to project-relative by `zccache::path_arg_for_compile_cwd`, and GCC resolves them correctly against `cwd = <project>/`. test-emu passes the raw `.build/pio/<env>` *relative* string, which propagates straight into `discover_project_includes` and produces relative include paths like `-I.build/pio/esp32dev/lib/FastLED`. The zccache normalizer short-circuits on non-absolute inputs and passes them through unchanged. GCC then resolves the relative include against the already-project-rooted compile cwd, doubling the prefix to `<project>/.build/pio/esp32dev/lib/FastLED` — a path that doesn't exist — and FastLED.h is reported missing. Fix: promote `project_dir` to an absolute path at the top of `discover_project_includes` via the existing `absolute_from_cwd` helper (made `pub` for cross-module use). Every emitted include dir is now absolute regardless of how the caller spelled the input, so the normalize→exec chain is stable. Regression tests cover both absolute and relative `project_dir` inputs and assert the absolutization invariant. Full fbuild-build test suite: 546/546 passing. Fixes #303
9d9db68 to
24a671a
Compare
Summary
fbuild test-emu .build/pio/<env>was failing every ESP32 QEMU CI run withfatal error: FastLED.h: No such file or directoryeven though the precedingci-compile.pystep had just produced a working firmware in the same project directory.Issue described in #303.
Root cause
The CLI passes the project-dir argument through verbatim to the daemon, which builds a
PathBuffrom the string and hands it to the orchestrator unchanged. Whether the path is absolute or relative depends entirely on what the user typed.ci-compile.pyinvokes fbuild with an absolute project dir (workspace-rooted).discover_project_includesproduces absolute include flags.zccache::path_arg_for_compile_cwdstrips the compile-cwd prefix, leaving project-relative include flags that GCC resolves correctly againstcwd = <project>/.fbuild test-emu .build/pio/<env>(the CI form) sends a relative path.discover_project_includesjoins it as-is, producing relative include paths like-I.build/pio/esp32dev/lib/FastLED.zccache::path_arg_for_compile_cwdshort-circuits on non-absolute inputs (if !path.is_absolute() { return path.to_string_lossy().to_string(); }) and passes them through unchanged. GCC then resolves the already-relative include path against the project-rooted compile cwd, producing the doubled prefix<project>/.build/pio/esp32dev/lib/FastLED-- which doesn't exist -- andFastLED.his reported missing.The bug had nothing to do with lib-discovery logic (the original hypothesis in #303).
discover_project_includesalready implements PlatformIO'slib/<Name>/src/auto-discovery correctly. The output of that discovery was just spelled in a form that survived too far through the compile-cwd plumbing.Fix
discover_project_includesnow callsabsolute_from_cwd(project_dir)at the top, making every emitted include dir absolute regardless of how the caller spelled the input. The normalize-then-exec chain then behaves identically for absolute and relative call sites.absolute_from_cwdalready existed incompiler.rsaspub fn absolute_from_cwd(path: &Path) -> PathBuf(used for source and output paths incompile_sourceto fix the analogous #282 bug). Promoted from private topubfor cross-module use.Why this is the right layer
Three places could host the fix; pipeline-level is the smallest blast radius:
build,test_emu,deploy): would have to canonicalize on every handler; easy to miss new entry points.zccache::path_arg_for_compile_cwd: would have to look upcurrent_dir()for every relative path; couples the helper to process state.discover_project_includes(chosen): one call, single responsibility (emit absolute include paths), already documents that callers should not depend on relativeness.Test plan
cargo test --lib -p fbuild-build pipeline::project_discovery-- 2/2 new regression tests passingcargo test --lib -p fbuild-build-- 546/546 passingqemu_esp32dev_test,qemu_esp32s3_test,qemu_esp32c3_testshould turn green once a release of fbuild ships and FastLED bumps its pin.Fixes #303
Generated with Claude Code (https://claude.com/claude-code)