Repository navigation
Fail fast on unsupported advanced PlatformIO build options in platformio.ini #35
Description
Parent: #34
Problem
Today fbuild warns for unsupported PLATFORMIO_* environment variables, but it does not appear to inspect platformio.ini itself for advanced PlatformIO build options that it cannot honor. That creates the worst failure mode here: a project builds, but with materially different semantics.
Relevant repo evidence
- CLI already warns for unsupported/no-op
PLATFORMIO_*env vars:crates/fbuild-cli/src/main.rs:421-430 PLATFORMIO_EXTRA_SCRIPTSis explicitly warn-only/no-op today:crates/fbuild-config/src/pio_env.rs:43-60BuildContext::new()only collectsbuild_flagsandbuild_src_flags:crates/fbuild-build/src/pipeline.rs:106-111- fbuild already has an explicit PlatformIO passthrough mode:
crates/fbuild-cli/src/main.rs:849-903
Why this matters
PlatformIO treats build_type, debug_build_flags, build_unflags, and extra_scripts as part of normal project configuration. If fbuild ignores those keys but still proceeds, users get a syntactically successful build with semantically different flags.
Requested change
Add an early configuration validation pass over platformio.ini that detects advanced build options which fbuild cannot yet honor and fails fast with a clear diagnostic.
Initial detection set
build_typedebug_build_flagsbuild_unflagsextra_scripts- any future advanced build option that changes effective flags or source selection without native support
Suggested UX
- Error before dependency resolution / build orchestration
- Explain which keys were found and why they are not yet honored
- Recommend
fbuild ... --platformioas the compatibility escape hatch when appropriate - Keep pure warnings only for cases that are truly no-op-safe
Acceptance criteria
- A project with unsupported advanced options in
platformio.inidoes not silently continue in native mode - The diagnostic names the offending option(s)
- The diagnostic points users to
--platformio - Tests cover both INI-based detection and env-var-based warnings so the behavior is consistent
Activity
zackees commentedon Apr 17, 2026
Looks like this is already resolved in the current tree. Verified by reading
crates/fbuild-build/src/pipeline.rsandcrates/fbuild-build/src/script_runtime.rs:build_type— honored atpipeline.rs:119, withdebugswitching toapply_debug_build_type()(pipeline.rs:124-134). Default falls back to"release"inget_build_type()(fbuild-config/src/ini_parser.rs:189-196).debug_build_flags— read atpipeline.rs:125and applied whenbuild_type == "debug". Defaults to PlatformIO's-Og -g2 -ggdb2when unset (ini_parser.rs:201-211).build_unflags— read atpipeline.rs:135and applied touser_flags,src_flags, andoverlay_link_flagsviaapply_build_unflags()+remove_unflagged_tokens()(pipeline.rs:136-138). HonorsPLATFORMIO_BUILD_UNFLAGSoverride.extra_scripts— executed via a Python harness inscript_runtime::resolve_extra_script_overlay()(script_runtime.rs:23-145), called atpipeline.rs:58-59. If Python is missing, the build fails fast with a diagnostic pointing to--platformio.The remaining narrow gap — that
build_unflagsdoes not yet strip flags contributed by framework compilation commands added inside each platform orchestrator — is what #37 specifically tracks.So the original premise of this issue ("fbuild ignores these keys silently, fail fast instead") no longer applies — they're honored. Closing in favor of #37 for the orchestrator-level scope.