stm32: Arduino_Core_STM32 framework libraries (SPI, Wire, ...) not discovered — fatal error: SPI.h: No such file or directory

[zackees]

Summary

FastLED CI started routing STM32 boards through fbuild after FastLED commit 82afa960b ("ci: make fbuild the default for board builds", 2026-04-23), and every STM32 board now fails because fbuild's STM32 orchestrator does not add Arduino_Core_STM32 framework library include paths. The failure signature is identical to the previously-fixed Teensy bug #163 / PR #164.

Evidence

Failing FastLED job (fbuild 2.2.3, 2026-04-24):
https://github.com/FastLED/FastLED/actions/runs/24910761486/job/72951522762

    0.00 =   BUILDING stm32f103c8   =
    0.00 Board: BluePill F103C8 / STM32F103C8T6 @ 72MHz
    0.04 Toolchain: arm-none-eabi-gcc 15.2.1
    8.42 Compiled 196/196 files
    8.70 Compiled 4/4 files
build error: build failed: compilation failed for .../src/main.cpp:
.../FastLED/platforms/arm/stm32/fastspi_arm_stm32.h:11:14: fatal error: SPI.h: No such file or directory
   11 |     #include <SPI.h>

The Arduino core and SrcWrapper (196 files) compile fine; the failure is limited to the sketch translation unit that transitively includes <SPI.h>.

All STM32 boards fail:

• stm32f103c8_bluepill — https://github.com/FastLED/FastLED/actions/runs/24910761486
• stm32f411ce_blackpill — https://github.com/FastLED/FastLED/actions/runs/24910761453

Pre-switch (run 24821237314, 2026-04-23, using pio run) — all STM32 boards passed.

Root cause

fbuild successfully downloads the STM32duino framework package. SPI.h exists in the fbuild cache at:

~/.fbuild/prod/cache/platforms/stm32duino-Arduino_Core_STM32/<hash>/2.9.0/Arduino_Core_STM32-2.9.0/libraries/SPI/src/SPI.h

Other bundled libraries are also present: EEPROM, Wire, Servo, SoftwareSerial, USBDevice, SrcWrapper, IWatchdog, Keyboard, Mouse, SubGhz, VirtIO, RGB_LED_TLC59731, CMSIS_DSP.

The STM32 orchestrator installs the core and toolchain but doesn't walk libraries/*/src/ and add those include dirs to the sketch's compile command — exactly the bug pattern that #163 described for Teensy and that #164 fixed by adding Teensyduino framework-library include discovery.

Reproduction

In a FastLED checkout on master:

./compile --no-interactive --no-parallel --log-failures failures --max-failures 1 stm32f103c8 Blink

Reproduces locally on Windows with fbuild 2.2.3 and in CI on Ubuntu. Full failure reproduces in ~20s after the 196-file core compile.

Minimal sketch that triggers it (FastLED examples/Blink/Blink.ino is sufficient):

#include <FastLED.h>   // transitively -> platforms/arm/stm32/fastspi_arm_stm32.h -> <SPI.h>
void setup() {}
void loop() {}

Generated platformio.ini (from FastLED CI):

[env:stm32f103c8]
board = bluepill_f103c8
platform = https://github.com/platformio/platform-ststm32.git
framework = arduino
lib_ldf_mode = chain
lib_archive = true

Expected behavior

fbuild STM32 builds should resolve and expose Arduino_Core_STM32 bundled framework libraries to sketches — at minimum SPI — matching PlatformIO's LDF behavior for framework = arduino on ststm32.

The libraries/*/src/ subdirs of the Arduino_Core_STM32 package should be discovered and added as include paths (and, for libraries with sources, compiled and linked) the same way PR #164 did for the Teensyduino package.

Suggested direction

Mirror the fix from #164 in the STM32 orchestrator:

• Scan <framework>/libraries/*/ inside the Arduino_Core_STM32 package.
• Skip examples/, extras/, tests/.
• Select only libraries transitively referenced by project sources (same selection logic PR Fix Teensy framework library resolution #164 introduced for Teensy).
• Add their src/ (or root, per Arduino library spec) to the sketch's include path.
• Compile library sources when present; SPI specifically has SPI.cpp and needs linking.

Relevant fbuild code (by analogy with PR #164):

• crates/fbuild-build/src/stm32/orchestrator.rs (or equivalent)
• crates/fbuild-packages/src/library/ (add stm32_core.rs modeled after teensy_core.rs)

Impact

All STM32 FastLED boards fail in CI until this is fixed. FastLED could add STM32 back to an allowlist and restore PlatformIO as the backend for STM32 as a workaround, but the proper fix belongs in fbuild.

Versions

• fbuild 2.2.3 (also reproduced in 2.2.1 in prior CI runs after the default switch)
• FastLED master @ 0dfcea64a

[zackees]

For visibility — already closed, but worth recording the resolution path:

The STM32 SPI auto-discovery problem was symptomatic of the same root cause as #204: the old basename-matching resolver couldn't reliably attribute <SPI.h> to STM32duino's Arduino_Core_STM32/libraries/SPI/.

PR #207 replaced the resolver with fbuild-library-select, which uses path-prefix attribution and matches PlatformIO's LDF semantics. The walker resolves <SPI.h> via the framework's include path and attributes the result to the SPI library by prefix — no manual allowlist needed.

PR #208 added the regression gate at crates/fbuild-build/tests/stm32_acceptance.rs. It builds an stm32f103c8 sketch with <SPI.h> and asserts:

• SPIClass symbol present in the ELF
• An SPI library entry appears in compile_commands.json

The gate runs in CI via the acceptance workflow added in PR #211 (this PR's follow-up).