Parent: #34
Problem
PlatformIOConfig::from_path_with_overrides() stores a PioEnvOverrides snapshot and its docs say getters should honor caller-provided PLATFORMIO_* overrides. In practice, only some getters do. Several build-relevant getters appear to ignore the attached overrides entirely.
Relevant repo evidence
PlatformIOConfig stores overrides and documents that getters should consult them: crates/fbuild-config/src/ini_parser.rs:27-47
get_build_flags() reads only config.get("build_flags"): crates/fbuild-config/src/ini_parser.rs:123-135
get_build_src_flags() reads only config.get("build_src_flags"): crates/fbuild-config/src/ini_parser.rs:137-143
get_default_environment() reads only [platformio].default_envs: crates/fbuild-config/src/ini_parser.rs:95-121
PioEnvOverrides exposes accessors for PLATFORMIO_BUILD_FLAGS, PLATFORMIO_BUILD_SRC_FLAGS, PLATFORMIO_BUILD_UNFLAGS, PLATFORMIO_BUILD_SRC_FILTER, and PLATFORMIO_DEFAULT_ENVS: crates/fbuild-config/src/pio_env.rs:111-125
Why this matters
The CLI forwards PLATFORMIO_* env vars to the daemon specifically so the daemon can behave like PlatformIO without inheriting the caller environment. If the getters do not use those forwarded values, native builds can diverge from PlatformIO even before we get into SCons/advanced scripting territory.
Requested change
Audit all declared supported PLATFORMIO_* overrides and make the actual config getters honor them consistently, or downgrade any unimplemented ones to warning-only/unsupported status.
Priority candidates
PLATFORMIO_BUILD_FLAGS
PLATFORMIO_BUILD_SRC_FLAGS
PLATFORMIO_BUILD_UNFLAGS
PLATFORMIO_BUILD_SRC_FILTER
PLATFORMIO_DEFAULT_ENVS
Acceptance criteria
- Every env var listed as supported either changes runtime behavior or is reclassified
- Tests cover forwarded overrides through
PlatformIOConfig::from_path_with_overrides()
- The supported/no-op/unsupported classification in
pio_env.rs matches reality
Parent: #34
Problem
PlatformIOConfig::from_path_with_overrides()stores aPioEnvOverridessnapshot and its docs say getters should honor caller-providedPLATFORMIO_*overrides. In practice, only some getters do. Several build-relevant getters appear to ignore the attached overrides entirely.Relevant repo evidence
PlatformIOConfigstoresoverridesand documents that getters should consult them:crates/fbuild-config/src/ini_parser.rs:27-47get_build_flags()reads onlyconfig.get("build_flags"):crates/fbuild-config/src/ini_parser.rs:123-135get_build_src_flags()reads onlyconfig.get("build_src_flags"):crates/fbuild-config/src/ini_parser.rs:137-143get_default_environment()reads only[platformio].default_envs:crates/fbuild-config/src/ini_parser.rs:95-121PioEnvOverridesexposes accessors forPLATFORMIO_BUILD_FLAGS,PLATFORMIO_BUILD_SRC_FLAGS,PLATFORMIO_BUILD_UNFLAGS,PLATFORMIO_BUILD_SRC_FILTER, andPLATFORMIO_DEFAULT_ENVS:crates/fbuild-config/src/pio_env.rs:111-125Why this matters
The CLI forwards
PLATFORMIO_*env vars to the daemon specifically so the daemon can behave like PlatformIO without inheriting the caller environment. If the getters do not use those forwarded values, native builds can diverge from PlatformIO even before we get into SCons/advanced scripting territory.Requested change
Audit all declared supported
PLATFORMIO_*overrides and make the actual config getters honor them consistently, or downgrade any unimplemented ones to warning-only/unsupported status.Priority candidates
PLATFORMIO_BUILD_FLAGSPLATFORMIO_BUILD_SRC_FLAGSPLATFORMIO_BUILD_UNFLAGSPLATFORMIO_BUILD_SRC_FILTERPLATFORMIO_DEFAULT_ENVSAcceptance criteria
PlatformIOConfig::from_path_with_overrides()pio_env.rsmatches reality