Skip to content

Define native support boundaries for PlatformIO extra_scripts env/projenv mutations #38

@zackees

Description

@zackees

Parent: #34

Problem

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.

PlatformIO docs/source evidence

  • env is the global construction environment; projenv is the isolated environment for src_dir; PRE scripts affect both, POST scripts can target only projenv: https://docs.platformio.org/en/latest/scripting/construction_environments.html
  • 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:

  1. Which script patterns are candidates for a compatibility subset?
  2. Which patterns must be rejected outright?
  3. How will fbuild distinguish env-scope mutations from projenv-scope mutations?
  4. 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:
    • Append
    • AppendUnique
    • maybe Replace
  • limited to:
    • CPPDEFINES
    • CCFLAGS
    • CXXFLAGS
    • LINKFLAGS
    • CPPPATH

Suggested explicit non-goals unless proven otherwise

  • arbitrary Python execution effects
  • hooks/actions (AddPostAction, custom targets, delayed actions)
  • custom builders / middleware
  • mutation of package resolution or upload behavior

Acceptance criteria

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions