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
Research whether PlatformIO __idedata / project metadata can support a scripted-project bridge #39
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:
Inventory exactly what __idedata / pio project metadata exposes
Compare that to what fbuild needs for native compile/link/deploy parity
Identify hard blockers for scripted projects
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
__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.
Activity
zackees commentedon Apr 17, 2026
__idedata/pio project metadatais 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_scriptsoverlay (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 likeuploadandsize, 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.