Skip to content

feat(toolchain): backend abstraction (CommandDialect) + MinGW-w64 via the xlings ecosystem — 0.0.89#211

Merged
Sunrisepeak merged 7 commits into
mainfrom
feat/toolchain-dialect-mingw
Jul 13, 2026
Merged

feat(toolchain): backend abstraction (CommandDialect) + MinGW-w64 via the xlings ecosystem — 0.0.89#211
Sunrisepeak merged 7 commits into
mainfrom
feat/toolchain-dialect-mingw

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Summary

Implements Parts A + B of .agents/docs/2026-07-13-toolchain-backend-abstraction-msvc-mingw-design.md (companion audit: 2026-07-13-compiler-dialect-touchpoint-audit.md) in one PR, per plan. Part C (native MSVC cl.exe build backend) is the next round and builds on A.

Part A — toolchain backend abstraction (zero behavior change)

  • New mcpp.toolchain.dialect: command-line spellings as a value-traits table (gnu shared by GCC/Clang/MinGW; msvc row ready for the cl.exe backend). flags.cppm + ninja rule templates now spell -I/-D/-std=/-c/-o/-O/-g and the archive command through it.
  • BmiTraits gains module-flag spellings — flags.cppm's is_clang module branches are now data-driven.
  • ProviderCapabilities.has_builtin_p1689_scan replaces ninja_backend's is_gcc scanner gate.
  • Toolchain::envOverrides (EnvVar list → ninja child env): the seam for the MSVC backend's INCLUDE/LIB/PATH.
  • gcc::std_module_build_commands normalizes the provider surface (command-sequence shape, same as clang).
  • resolve_link_model: explicit empty PE model, keyed on the target (msvc/mingw triples).
  • Zero-diff gate passed: build.ninja byte-identical (modulo the mcpp self-path var) for GCC and LLVM on a multi-module import-std project.

Part B — MinGW-w64 GCC via the xlings ecosystem

mcpp toolchain install mingw 16.1.0 / default mingw@16.1.0xim:mingw-gcc (winlibs GCC 16.1.0 + MinGW-w64 14.0.0 UCRT standalone, mirrored at xlings-res/mingw-gcc — GitHub + GitCode, GET-verified 200/284579900 both ends; index: openxlings/xim-pkgindex#382, merged).

  • Reuses the GCC backend end-to-end (gcm pipeline, import std via bits/std.cc) — first fully working Windows-native GCC toolchain in mcpp, no Visual Studio required.
  • Portable-by-default: -static link (winlibs' documented recipe — CI import tables proved the piecemeal recipe loses to driver implicit libs) + -lstdc++exp (std::print's __open_terminal); opt-out [build] static_stdlib=false.
  • Rode-along fixes: Available/partial-version listing used hardcoded 'linux' platform (empty on win/mac); toolchain install no longer pulls glibc/linux-headers on win/mac.

Verified on Windows CI (temp PR #209, green run 29233042340)

  • e2e 52 passed / 0 failed incl. 97_mingw_toolchain.sh: install → default → multi-module import-std build/run → standalone exe (imports: KERNEL32 + UCRT api-ms-* only).
  • Dedicated steps: MinGW install→build→run PASS; MSVC detection PASS.

Version

0.0.89 (mcpp.toml + fingerprint.cppm + CHANGELOG).

…Part A)

New mcpp.toolchain.dialect: command-line *spellings* (gnu vs msvc) as a
value-type traits table — flags.cppm and ninja rule templates now spell
-I/-D/-std=/-c/-o/-O/-g/ar-invocations through it instead of hardcoding
GNU syntax. BmiTraits gains the module-flag spellings (compileModulesFlag,
stdBmiUsePrefix, moduleOutputPrefix, bmiSearchPrefix), replacing the
is_clang()/stdlib_id branches in flags.cppm. ProviderCapabilities gains
has_builtin_p1689_scan (drops ninja_backend's is_gcc gate). Toolchain gains
envOverrides (EnvVar list — std::pair member trips GCC-16 module pendings)
merged into ninja's child env; the MSVC backend will carry INCLUDE/LIB/PATH
through it. gcc::std_module_build_commands normalizes the provider surface
to the command-sequence shape clang already has. resolve_link_model returns
the empty PE model explicitly on Windows.

Zero-diff verified: build.ninja byte-identical (modulo the mcpp self-path
var) for GCC and LLVM toolchains on a multi-module import-std project;
mcpp test 31/31.
…) (0.0.89)

User-facing 'mingw' spec → xim:mingw-gcc (winlibs GCC 16.1.0 + MinGW-w64
14.0.0 UCRT standalone build, mirrored at xlings-res/mingw-gcc). Reuses the
GCC backend end-to-end (gcm module pipeline, bits/std.cc import std);
Windows adds static libstdc++/libgcc defaults so produced exes run
standalone, and -static under linkage="static". archive_tool resolves the
bundled ar.exe; std.cc lookup gains a version-dir scan fallback.

Fixes ridden along: toolchain list 'Available' + partial-version resolution
read xpkg versions for the HOST platform (was hardcoded linux — empty on
win/mac); toolchain install no longer pulls glibc/linux-headers on win/mac.

e2e 97 (requires: windows cap) + ci-windows MinGW step + unit tests
(dialect rows, mingw spec mapping); docs + CHANGELOG; version 0.0.89.
The Windows-host if-constexpr broke the linkmodel contract tests on
Windows CI (they resolve synthetic Linux-shaped toolchains anywhere).
Target-keyed is also the semantics a future cross build needs.
std::vprint_unicode's __open_terminal/__write_to_terminal live in
libstdc++exp.a on Windows-GCC targets — first real MinGW link on CI failed
with undefined references from bits/print.h.
winlibs POSIX-threads libstdc++ otherwise leaves produced exes depending on
libwinpthread-1.dll — the standalone-exe e2e caught it (empty output,
missing-DLL abort). -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic is the standard
recipe; libwinpthread.a ships in the payload.
The silent standalone-run failure gave nothing to debug — inspect DLL
imports directly and dump them on any failure.
…cipe loses to driver implicit libs

CI import table still showed libwinpthread-1.dll after
-Wl,-Bstatic -lwinpthread; winlibs' documented answer for standalone exes
is a full -static link (system DLLs still resolve via import libs).
Gated on staticStdlib so [build] static_stdlib=false opts out.
@Sunrisepeak Sunrisepeak merged commit f6fd39e into main Jul 13, 2026
6 checks passed
@Sunrisepeak Sunrisepeak deleted the feat/toolchain-dialect-mingw branch July 13, 2026 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant