You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Define native support boundaries for PlatformIO extra_scripts env/projenv mutations #38
extra_scripts is the real boundary between a pragmatic compatibility shim and ?becoming a SCons host?. PlatformIO exposes both the global construction environment (env) and the isolated project environment (projenv), and scripts can mutate CPPDEFINES, CCFLAGS, CXXFLAGS, LINKFLAGS, CPPPATH, LIBPATH, LIBS, actions, custom targets, and more.
extra_scripts is a first-class advanced project option: .cache/platformio-core/platformio/project/options.py:809-818
PlatformIO's tests rely on projenv.Append(CPPDEFINES=...) and env.Append(...) to affect builds: .cache/platformio-core/tests/commands/test_run.py:35-140, .cache/platformio-core/tests/commands/test_run.py:143-169
Current fbuild state
PLATFORMIO_EXTRA_SCRIPTS is currently recognized as warn-only / no-op: crates/fbuild-config/src/pio_env.rs:43-60
Native fbuild has no SCons environment model; it assembles flags directly in Rust orchestrators
Requested change
Write down the support boundary for extra_scripts in native mode and turn it into an implementable plan.
At minimum this issue should answer:
Which script patterns are candidates for a compatibility subset?
Which patterns must be rejected outright?
How will fbuild distinguish env-scope mutations from projenv-scope mutations?
When should native mode fail fast and recommend --platformio?
Suggested initial compatibility candidates
very small subset of flag mutations on env / projenv for known scopes:
Activity