fix(daemon): resolve a relative project dir against the caller's cwd

[zackees]

Fixes #1441.

Root cause

It isn't about header-only libraries. fbuild ci/kitchensink build sent the daemon the relative string ci/kitchensink, and the build handler used it as-is (PathBuf::from(&req.project_dir)). Every path derived from it stayed relative: the build dir, libs/, and each downloaded library's -I flag. Meanwhile the compiler runs from the absolute project dir. So the sketch got

-Ici/kitchensink/.fbuild/build/dev/release/libs/arduinojson/src/src

which, resolved from …/ci/kitchensink, points nowhere, and the build failed with fatal error: ArduinoJson.h: No such file or directory. symlink:// libraries were already canonicalised (resolve_local_library_dir), which is why FastLED itself was found. The handler also read the relative path against the daemon's cwd, which only matched the caller's by accident.

Fix

• CLI: resolve_project_dir() sends an absolute path (std::path::absolute, lexical, no symlink resolution).
• Daemon: the build, deploy and install-deps handlers resolve a relative project_dir against the request's caller_cwd (resolve_request_project_dir), so every client gets the same answer.

Validation

• 4 unit tests for resolve_request_project_dir: a relative path joined onto caller_cwd, an absolute path kept, no caller_cwd still producing an absolute path, and ..
• End to end, with FastLED's ci/kitchensink (fix(ci): port the kitchensink project to fbuild FastLED#4429) run as fbuild ci/kitchensink build in dev mode: the build now compiles and links with #include <ArduinoJson.h> (309 KB). The sketch's ArduinoJson flag is now -I/home/…/ci/kitchensink/.fbuild/build/dev/release/libs/arduinojson/src/src. That run also needed fix(esp32): build a pre-unified-toolchain platform pin against stable #1446's platform fix, since the project pins pioarduino 51.03.04.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Project directories are now resolved consistently against the caller’s working directory, improving build, deployment, and dependency installation when relative paths are used.
  • Absolute paths and the default current-directory behavior continue to work as expected.

• Tests

  • Added coverage for relative, absolute, missing-working-directory, and default project path scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: d95abb84-a957-411f-be0a-2ad854d60c51

📥 Commits

Reviewing files that changed from the base of the PR and between cbfbfa3 and a789d36.

📒 Files selected for processing (6)

• crates/fbuild-cli/src/cli/args.rs
• crates/fbuild-daemon/src/handlers/operations/build.rs
• crates/fbuild-daemon/src/handlers/operations/common.rs
• crates/fbuild-daemon/src/handlers/operations/deploy.rs
• crates/fbuild-daemon/src/handlers/operations/install_deps.rs
• crates/fbuild-daemon/src/handlers/operations/tests.rs

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The CLI and daemon now convert project directories to absolute paths. Relative daemon requests use the caller’s working directory. Build, deploy, and dependency installation handlers use the shared resolver. Tests cover relative, absolute, missing-cwd, and "." paths.

Changes

Project Directory Resolution

Layer / File(s)	Summary
Path resolution and validation crates/fbuild-cli/src/cli/args.rs, crates/fbuild-daemon/src/handlers/operations/common.rs, crates/fbuild-daemon/src/handlers/operations/tests.rs	The CLI and daemon resolve project directories lexically to absolute paths. Relative request paths use the caller’s cwd when provided. Tests cover the supported path forms.
Operation path wiring crates/fbuild-daemon/src/handlers/operations/build.rs, crates/fbuild-daemon/src/handlers/operations/deploy.rs, crates/fbuild-daemon/src/handlers/operations/install_deps.rs	Build, deploy, and dependency installation operations use the shared project-directory resolver before validation and subsequent path operations.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to a789d

The caller-relative path handling is consistently applied across the affected operations, with no actionable current-head risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: resolving relative project directories against the caller's working directory in the daemon.
Linked Issues check	✅ Passed	This PR implements the required fix for issue #1441. The issue reported that header-only registry libraries were downloaded but not added to the include path because paths derived from relative projec…
Out of Scope Changes check	✅ Passed	All changes remain within scope of issue #1441. The modifications to CLI path resolution (args.rs), daemon path resolution (build.rs, deploy.rs, install_deps.rs), the centralized helper (common.rs), a…
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 6 files.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}