Repository navigation
Apply PlatformIO build_unflags to the effective native flag scopes #37
Description
Parent: #34
Problem
build_unflags is more than user-flag cleanup. PlatformIO applies it against the effective SCons environment after board flags, user flags, framework scripts, and other mutations have contributed to the final flag scopes.
PlatformIO source evidence
ProcessProgramDeps()applies board extra flags, thenBUILD_FLAGS, then framework scripts, thenConfigureDebugTarget(), and only after that callsProcessUnFlags(BUILD_UNFLAGS):.cache/platformio-core/platformio/builder/tools/piobuild.py:94-128ProcessUnFlags()removes matching entries across parsed flag scopes, includingASPPFLAGS:.cache/platformio-core/platformio/builder/tools/piobuild.py:256-266- PlatformIO has a regression test where
build_unflagsremoves values injected by anextra_scriptsSCons mutation, not just values typed directly inbuild_flags:.cache/platformio-core/tests/commands/test_run.py:143-197
Current fbuild state
PLATFORMIO_BUILD_UNFLAGSis recognized as supported and has an accessor:crates/fbuild-config/src/pio_env.rs:15-21,crates/fbuild-config/src/pio_env.rs:111-121- I could not find any code path where those unflags are applied to the effective native flag set
- fbuild currently merges user flags by appending/replacing some flag classes, e.g. ESP32
apply_user_flags():crates/fbuild-build/src/esp32/orchestrator.rs:1257-1276
Requested change
Implement build_unflags in native mode against the final effective flag scopes that fbuild assembles, not only against raw user-provided build_flags.
Questions to resolve
- Which scopes should be covered in fbuild (
compile,link, assembler, include paths, libs)? - Should support be exact-match only, or also special-case macro/key semantics as fbuild already does for
-Dreplacement? - How should this interact with platform-specific orchestrators that currently assemble flags differently?
Acceptance criteria
build_unflagsaffects the effective native build result- Removal is applied after board/framework/profile/user contributions are combined
- Tests cover at least one removal from each supported scope
- If any PlatformIO
build_unflagsbehavior is intentionally out of scope, the limitation is documented and diagnosed clearly
Activity
feat(build): apply build_unflags to framework compile flags, ESP32 wi…
feat(build): apply build_unflags to framework compile flags, ESP32 wi…
feat(build): wire build_unflags through all remaining platform compil…
feat(build): wire build_unflags through all remaining platform compil…
zackees commentedon Apr 17, 2026
Resolved across all platforms.
PR feat(build): apply build_unflags to framework compile flags, ESP32 wired (#37) #63 introduced the trait-level mechanism: new `Compiler::build_unflags()` method with default `&[]`, default `compile_c`/`compile_cpp` impls filter both platform and user flags through `pipeline::remove_unflagged_tokens` when non-empty, and `BuildContext` gained a `build_unflags` field. ESP32 was wired as the reference implementation.
PR feat(build): wire build_unflags through all remaining platform compilers (#37) #64 wired the same pattern through every other platform: AVR, Teensy, generic ARM (STM32 / RP2040 / Apollo3), nRF52, Renesas, Silabs, CH32V, SAM, and ESP8266.
Scope covered:
Tests cover trait default returning empty, configured unflags round-tripping through the trait method, and end-to-end stripping of a framework-contributed `-std=gnu++2b`.
Closing.