Repository navigation
fix(esp): honor or reject IDF framework requests instead of silently building Arduino #1664
Description
Context
During FastLED/FastLED#4773 validation, esp32dev_idf5_component passes with framework=arduino, espidf, but this does not exercise ESP-IDF CMake/component integration.
Verified in two rounds:
- Exact fbuild tag v2.5.37, commit a03aaa5:
crates/fbuild-build-esp/src/esp32/orchestrator/build.rscallsresolve_pioarduino_packages;packages.rsresolves the Arduino-backedEsp32Framework. - The staged project preserves the dual framework option, but build metadata identifies
fbuild compile_commands.json; compile commands build Arduinocores/esp32/main.cpp, generated sketchsrc/main.cpp, and native FastLED library objects. No CMake configuration artifacts demonstrateidf_component_register()execution.
FastLED's current ci/boards.py comments describe historical CMake coverage. Its root component CMake contract also requires arduino-esp32, so bare-IDF coverage remains independently unproven. FastLED#3724 was closed but these coverage limitations remain.
Proposal
Make ESP framework selection explicit. Unsupported espidf or dual-framework requests must fail clearly instead of producing an Arduino-only success. Implement genuine component/bare-IDF support separately if required, with actual build-artifact evidence.
Acceptance criteria
- RED: a project requesting an IDF integration mode currently proceeds through the Arduino-only native build pipeline.
- GREEN: the requested framework is honored, or a precise unsupported-framework error rejects it before compilation.
- Metadata records the requested and effective frameworks and integration mode.
- Claim CMake/IDF coverage only after artifacts prove component registration and intended application entry point.
- Add regression coverage for both
framework=espidfandframework=arduino, espidf; preserve supported Arduino builds.
Decisions
- Track separately from FastLED's no-throw implementation; do not change production FastLED unity/build architecture for this validation gap.
- The existing component-named profile is valid Arduino-backed SDK coverage, not proof of CMake or bare-IDF integration.
- This concerns framework dispatch, distinct from preview reference resolution tracked in fix(esp32): honor VCS platform refs instead of resolving IDF6 preview to stable SDK5 #1662.
Activity
fix(esp32): reject framework = espidf instead of silently building Ar…
fix(esp32): reject framework = espidf instead of silently building Ar…
zackees commentedon Oct 28, 2026
Fixed on
main— closing with the evidence I re-verified today.8088892a(PR fix(esp32): reject framework = espidf instead of silently building Arduino (#1664) #1730,fix(esp32): reject framework = espidf instead of silently building Arduino) rejects a bareframework = espidfrequest before any build work, instead of building it as Arduino and reporting success.crates/fbuild-build-esp/src/esp32/orchestrator/helpers.rsonmainnow classifies the request (RequestedFrameworks): bareespidf→ unsupported-espidf error;arduino, espidf→ still builds, labelled as an Arduino-on-IDF build (that is a real Arduino-on-IDF build, not an IDF component build).0b0053ea(PR feat(esp32): record requested framework and integration mode in the package summary (#1664) #1766) additionally records the requested framework and integration mode in the package summary, so a build's choice is visible after the fact.bare_espidf_framework_is_rejected_before_building(plus the accept-path cases) incrates/fbuild-build-esp/src/esp32/orchestrator/tests.rs.Bare-IDF / CMake component builds remain out of scope and are tracked separately in #1761.
— fbuild steward (automated)
zackees commentedon Nov 3, 2026
Round-1 implementation plan (owner-requested ESP-IDF-only support):