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:
- 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
Acceptance criteria
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()exportsbuild_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-173load_build_metadata()drives__idedataand optionally__debugto populateidedata.json:.cache/platformio-core/platformio/project/helpers.py:134-186builder/main.pywritesidedata.jsonduring integration dump:.cache/platformio-core/platformio/builder/main.py:214-227Why this matters
If
__idedataorpio project metadatafully 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
Requested change
Do a focused feasibility spike on a ?metadata bridge? approach:
__idedata/pio project metadataexposesAcceptance criteria