fix(build): wire project_dir into board resolution on the daemon build path#518
Conversation
#516 introduced `BoardConfig::from_board_id_in_project(..., project_dir)` and updated `compile_many::platform_for_board` to use it, so `fbuild ci`'s batch path picked up `<project_dir>/boards/*.json`. But the daemon-backed single-build flow (`fbuild build <dir> -e <env>`, which 99% of users actually hit) goes through a different entry point: `BuildContext::new_with_perf` in `pipeline/context.rs`. That call site was still using the legacy `from_board_id(board_id, &overrides)` — no project_dir, so the project-local boards/ fallback never ran. Net effect: 2.2.23 shipped but `fbuild build .` against a project with a project-local `boards/` directory continued to fail with config error: unknown board 'lpc845brk' (no built-in defaults) This patch: - pipeline/context.rs: switch BuildContext board resolution to `from_board_id_in_project` with `Some(project_dir.as_path())`. The field was already in scope (line 61). - script_runtime.rs: thread `project_dir` into `build_script_runtime_board_config`, used by `extra_scripts` shim setup (also currently silently dropping the project_dir context). Now all three build-path board-resolution sites — `compile_many`, `pipeline::BuildContext`, `script_runtime` — use the same shared `from_board_id_in_project` helper. ## Verified locally Built `cargo build -p fbuild-cli -p fbuild-daemon`, ran target/x86_64-pc-windows-msvc/debug/fbuild.exe build <repo> -e lpc845brk against zackees/ArduinoCore-LPC8xx (real boards/lpc845brk.json present). Before: `unknown board 'lpc845brk' (no built-in defaults)`. After: prints `Board: NXP LPC845-BRK / LPC845 @ 30MHz` and progresses into the actual compile stage (next failure is downstream — fbuild's nxplpc orchestrator framework-ingestion is still at the Stage 3 stub per #479; out of scope here). cargo test -p fbuild-build --lib: 687 passed, 0 failed.
|
Warning Review limit reached
More reviews will be available in 2 minutes and 52 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 |
Ships the daemon-path board-resolution fix from #518 so `fbuild build <dir>` actually consults `<dir>/boards/<id>.json` for project-local board manifests. Without this 2.2.23 still fails with `unknown board 'X'` for ANY project that relies on project-local boards (LPC8xx is just the first real-world reproducer).
TL;DR
#516 added project-local
boards/*.jsonresolution but only wired it throughcompile_many. The far more common entry point —fbuild build <dir> -e <env>— goes throughBuildContexton the daemon side, which still uses the legacyfrom_board_id(no project_dir), so 2.2.23 still fails with:This PR points the daemon's build path at
from_board_id_in_project, completing the wiring for #515. All three production board-resolution sites —compile_many,pipeline::BuildContext,script_runtime— now sharefrom_board_id_in_project.What was happening
compile_many::platform_for_boardalready usedfrom_board_id_in_project, butcompile_manyis reached viafbuild ci/ batch flows, notfbuild build. Daily users hit the daemon path and saw zero benefit from #516.Patch
crates/fbuild-build/src/pipeline/context.rsfrom_board_id→from_board_id_in_project(board_id, &overrides, Some(project_dir.as_path())).project_dirwas already in scope (line 61).crates/fbuild-build/src/script_runtime.rsproject_dirthroughbuild_script_runtime_board_config(used byextra_scriptsoverlay setup) so it shares the same project-local fallback.No public API change.
Verification
Local repro before fix (
fbuild 2.2.22source-built off main):After fix:
(Hits a downstream failure that's the nxplpc orchestrator's framework-ingestion Stage 3 stub —
LED_BUILTINnot declared because the variant header isn't pulled in. That's #479 territory, out of scope here.)Tests
Related
LED_BUILTIN/ framework-ingestion gap belongs to Arduino-compatible framework for NXP LPC8xx (search existing, fork, or polyfill) #479 (Stage 3 external-framework checkout).