Skip to content

Research whether PlatformIO __idedata / project metadata can support a scripted-project bridge #39

Closed

Description

@zackees

Parent: #34

Problem

Before committing to full SCons compatibility, we should verify whether PlatformIO's existing metadata/export surfaces are rich enough to drive fbuild for scripted projects. If they are not, ?full support? likely means embedding or delegating to SCons/PlatformIO rather than merely importing resolved flags.

PlatformIO source evidence

  • DumpIntegrationData() exports build_type, defines, includes, cc_flags, cxx_flags, tool paths, targets, and some extra flash image data: .cache/platformio-core/platformio/builder/tools/piointegration.py:141-173
  • load_build_metadata() drives __idedata and optionally __debug to populate idedata.json: .cache/platformio-core/platformio/project/helpers.py:134-186
  • builder/main.py writes idedata.json during integration dump: .cache/platformio-core/platformio/builder/main.py:214-227

Why this matters

If __idedata or pio project metadata fully captured the resolved build graph, fbuild could potentially import it and keep native compilation/linking. If it only captures editor-oriented data, then it is insufficient for a full bridge and option (3) becomes much more expensive.

Initial gaps already visible

  • the integration dump exposes compile flags, but not a full resolved link command line
  • it does not obviously export all library archives/order needed for final linking
  • it does not capture action hooks / custom target behavior from scripts
  • it is designed for IDE integration, not for faithfully replaying the full PlatformIO build graph

Requested change

Do a focused feasibility spike on a ?metadata bridge? approach:

  1. Inventory exactly what __idedata / pio project metadata exposes
  2. Compare that to what fbuild needs for native compile/link/deploy parity
  3. Identify hard blockers for scripted projects
  4. Recommend one of:
    • viable bridge for a narrow subset
    • useful only for editor/intellisense parity
    • insufficient for build parity, so full support implies real SCons/PlatformIO delegation

Acceptance criteria

Activity

  1. zackees commented on Apr 17, 2026

    @zackees
    MemberAuthor

    __idedata / pio project metadata is good for IDE-style snapshots, but it is not enough to underpin a general scripted-project bridge.

    PlatformIO's integration dump serializes resolved editor-facing data such as build_type, defines, include paths, cc_flags, cxx_flags, tool paths, targets, and some extra flash image data (.platformio/penv/Lib/site-packages/platformio/builder/tools/piointegration.py, .platformio/penv/Lib/site-packages/platformio/builder/main.py, .platformio/penv/Lib/site-packages/platformio/project/helpers.py). It does not expose a resolved link command, archive ordering, custom target actions, or script provenance.

    On the fbuild side, native startup currently consumes config, board data, compile flags, and a limited extra_scripts overlay (crates/fbuild-build/src/pipeline.rs, crates/fbuild-build/src/script_runtime.rs, crates/fbuild-config/src/ini_parser.rs). Metadata alone is therefore insufficient to replay arbitrary scripted builds. The narrow viable subset is projects whose scripts collapse entirely into final env mutations already reflected in metadata; anything that generates sources, changes link order, or adds custom SCons/upload behavior still needs real PlatformIO/SCons delegation.

    I also spot-checked this on a local PlatformIO project with pio project metadata --json-output -e uno: the payload included compile flags, include roots, tool paths, and target names like upload and size, but not an executable build graph or custom action data.

    Conclusion: metadata import may be useful for editor/intellisense parity or a very narrow flag-only bridge, but it is not sufficient as the foundation for general scripted-project parity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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