Adapt to mcpp 2026.10.11.1: build.mcpp, its libraries and the engine interface in the build database #51

Summary

From mcpp 2026.10.11.1 (mcpp-community/mcpp#797, PRs mcpp-community/mcpp#798 and mcpp-community/mcpp#800; released 2026-10-11), build.mcpp and the libraries it imports are compiled by an ordinary plan, the build programs' graph. mcpp emit build-database describes that graph in the S1 document (SPEC-005 v1.8, R3.13). mcppls can now give build.mcpp, the libraries in [build-dependencies] and the engine interface (import mcpp; / import mcpp.core;) the same navigation, completion and diagnostics as target code. This issue states what the document contains and what mcppls needs to change.

compile_commands.json and --spec compile-commands do not contain these units. This is deliberate: build.mcpp and the engine interface are an mcpp-ecosystem convention.

What the document contains (mcpp ≥ 2026.10.11.1)

Example output: mcpp emit build-database --format json on a project with [build-dependencies] lib = { path = "../lib" } and a build.mcpp that does import mcpp; import lib;.

• arguments are the exact compile of the build programs' graph. .mcpp units carry an explicit language (-x c++ for GCC/Clang, /TP for MSVC). The work-directory is under the planning directory, as for every set of a planning pass.
• visible-sets of a build-program set lists only sets of the same graph. Target sets never see build-program sets, and the reverse holds too.
• One file in two sets. A package in both [dependencies] and [build-dependencies] has a target set (<pkg>) and a :host set. Their arguments may differ: features are per instance, and the build program has its own toolchain, standard and flags.
• The engine interface's sources live in engineModules (mcpp self env --format json → data.engineModules, e.g. ~/.mcpp/engine/2026.10.11.1/modules). They are written once per mcpp version and never edited, so treat them as read-only.
• When every build program is current, the command still plans the graph to describe it, without compiling.

What mcppls needs

1. Language association. Treat build.mcpp (any *.mcpp file) as C++ in the server and in the editor packages (VS Code contributes.languages, the other editor configs under editors/).
2. Set selection by configuration. A document under build.mcpp belongs to <pkg>:build. A library file present in two sets resolves its imports in the set matching the importing context. For a file opened directly, prefer the target set; offer the :host view only when the file is reached from build.mcpp.
3. Module resolution inside build-program sets. import mcpp; / import mcpp.core; resolves to the mcpp:core units, and import std; to mcpp:std:host. The BMIs of these sets are built with their own arguments, never with a target set's.
4. Read-only engine sources. Go-to-definition into mcpp:core opens files under engineModules. Mark them read-only, and do not offer edits or code actions there.
5. Diagnostics for build.mcpp come from the app:build arguments. A plugin unit (one that imports mcpp.core) reached from a target set is refused by mcpp (SPEC-007 P1). mcppls may show this as mcpp's diagnostic rather than an unresolved import.
6. Mock and conformance. src/bin/mockmcpp.cpp and the conformance fixtures need a document with these sets so the tests cover them. mcpp's e2e tests/e2e/913_the_build_database_describes_the_build_programs.sh is a reference fixture.
7. Version gate. These sets exist only from mcpp 2026.10.11.1. With an older mcpp the document has none of them, so keep the current behaviour.

References

• mcpp SPEC-005 R3.13 (docs/specs/build-database.md), SPEC-004 §12 (docs/specs/manifest-semantics.md), SPEC-007 §10 (build plugins).
• mcpp docs 30 — Libraries of a build program (docs/30-build-mcpp.md).
• Design: .agents/docs/2026-10-11-build-dependencies-one-pipeline-design.md §7 in mcpp.