Context
The current .ino preprocessing path emits #include <Arduino.h> into the generated .ino.cpp file unconditionally.
That is correct for Arduino-compatible builds, but it is too aggressive for targets or test environments where Arduino.h is not present. In those cases fbuild should not force Arduino semantics onto the generated translation unit.
Relevant area:
crates/fbuild-build/src/source_scanner.rs
Proposal
Only inject #include <Arduino.h> when Arduino.h is actually available/resolvable for the active build environment.
If Arduino.h is not available, omit the include and continue generating the .ino.cpp file without it.
Acceptance criteria
.ino preprocessing injects #include <Arduino.h> when the header is available.
.ino preprocessing omits #include <Arduino.h> when the header is not available.
- The behavior is covered by tests for both available and unavailable header cases.
- The generated output remains stable across repeated runs when inputs and header availability do not change.
Open questions
- What is the best availability check: board package metadata, include path probing, compiler preflight, or an existing build context signal?
Context
The current
.inopreprocessing path emits#include <Arduino.h>into the generated.ino.cppfile unconditionally.That is correct for Arduino-compatible builds, but it is too aggressive for targets or test environments where
Arduino.his not present. In those cases fbuild should not force Arduino semantics onto the generated translation unit.Relevant area:
crates/fbuild-build/src/source_scanner.rsProposal
Only inject
#include <Arduino.h>whenArduino.his actually available/resolvable for the active build environment.If
Arduino.his not available, omit the include and continue generating the.ino.cppfile without it.Acceptance criteria
.inopreprocessing injects#include <Arduino.h>when the header is available..inopreprocessing omits#include <Arduino.h>when the header is not available.Open questions