feat(codegen): 生成产物不再签入 —— protoc / grpc_cpp_plugin 由 mcpp 自建,用户 build.mcpp 只剩 3 行

[Sunrisepeak]

What

Generated protobuf/gRPC stubs are no longer checked in. mcpp builds protoc and grpc_cpp_plugin for your machine, out of the same packages you link, and generates the stubs during the build.

A project's entire build.mcpp is now three lines:

import mcpp;
import grpcgen;
int main() { return grpcgen::generate({"helloworld"}) ? 0 : 1; }

Why this shape

The mcpp.toml in this repo used to say:

gen/ holds protoc output, CHECKED IN on purpose. gRPC's codegen needs two host tools — protoc and grpc_cpp_plugin — and mcpp has no way to hand a dependency's built binaries to a consumer.

That stopped being true in mcpp 2026.8.5.1. Three properties follow, and none of them are achievable with hand-managed codegen:

	before	now
edit a .proto	re-run protoc by hand; forget and you ship stale stubs	a ninja edge re-runs, and only the affected one
protoc vs runtime version	your problem, and a mismatch fails at runtime	not expressible — a tool's version is its dependency's version
cross-compiling	find a host protoc yourself	correct by construction — tools always build for the build machine

The industry works hard for that middle row: Conan carries a protobuf/<host_version> placeholder, xmake deletes protoc outright when cross-compiling, and protobuf's own CMake still has an open issue where Protobuf_PROTOC_EXECUTABLE is ignored in CONFIG mode. Here it needs no machinery, because there is only one version axis.

Three packages, one tag

package	what it is	consumers write
mcpplibs.grpc	the gRPC runtime	grpc = "1.83.0"
mcpplibs.grpc-plugin	grpc_cpp_plugin	{ version = "1.83.0", tools = ["grpc_cpp_plugin"] }
mcpplibs.grpcgen	the codegen rule	{ version = "1.83.0", host-module = true }

A new CI job package-versions-match proves all three never drift — a 1.83.0 runtime with a differently-versioned plugin is exactly the mismatch this design exists to eliminate.

Why the plugin is its own package

This is the one decision I got wrong first and had to be corrected by data. The initial attempt put grpc_cpp_plugin in the main package behind a feature. It parses fine — and fails, because mcpp compiles a package into one object pool and a kind = "bin" target links all of it. Upstream's plugin links grpc_plugin_support + protobuf and touches the gRPC runtime not at all:

add_executable(grpc_cpp_plugin src/compiler/cpp_plugin.cc)
target_link_libraries(grpc_cpp_plugin grpc_plugin_support)

In the main package it would inherit OpenSSL, re2, c-ares and zlib. It failed outright:

error: xlings install_packages failed for 'compat.openssl@3.5.1'

A code generator failing because it cannot install TLS is not "big and slow" — it is the wrong dependency graph. Split out, it is 3 TUs + libprotoc: no TLS, no DNS, no regex engine.

Why the rule is its own package

Without it, every project copies ~60 lines of build.mcpp — which means copying bugs that then have to be fixed N times. At least one of those bugs is guaranteed to bite everyone: protoc does not embed the well-known types, so import "google/protobuf/timestamp.proto" is read from disk, and real services use Timestamp/Duration/Any constantly. The path is derivable from mcpp::dep_dir("protobuf") — 8 lines that belong in one versioned place, not in every project.

Rules ship as ordinary mcpp packages written in C++, so there is no second language here the way xmake has Lua rules and Bazel has Starlark.

The design doc originally deferred this, reasoning that a rule package "cannot carry its own tools". That reasoning was wrong — consumers declare grpc/grpc-plugin/protobuf in their own manifest anyway, so the tool env vars are already in the consumer's process. The real blockers were two bugs in mcpp 2026.8.5.1 (a rule could use neither import std; nor import mcpp;), fixed in 2026.8.5.2 — mcpp#357. Hence this repo's CI floor.

Two examples, deliberately

examples/greeter	templates/greeter instantiated — 3-line build.mcpp via grpcgen
examples/helloworld	the same program with the rule written out by hand, so the mechanism stays legible

CI builds both. Building examples/greeter is how the template gets tested — otherwise a broken template is only discovered by a user running mcpp new. A template-matches-example job byte-diffs the two build.mcpp files so they cannot drift.

Verification

• ✅ Output fidelity: the four files this self-built toolchain generates are byte-identical to those produced by official protoc 35.1 + the official gRPC plugin — verified for both the hand-written build.mcpp and the grpcgen rule.
• ✅ grpc = false path: full chain — generate → compile → link → run.
• ✅ grpc = true path: all four stubs generated.
• ✅ Incremental: editing a .proto re-runs only that edge (1.38s vs a 0.02s no-op), and a .proto that imports a sibling re-runs too.
• ✅ Tools land in the global store and are reused across projects.
• ⏳ The two examples' real RPC over loopback: not verifiable locally — this sandbox cannot install compat.openssl, which gRPC hard-requires. CI's linux + macOS legs cover it.

Ordering

mcpp-index #155 must land first — it adds compat.protobuf's protoc target. This is measured, not assumed: against the published index the plugin fails at link with

undefined symbol: typeinfo for google::protobuf::compiler::CodeGenerator

and succeeds against the index branch. After this merges and a release is tagged, a follow-up index PR adds mcpplibs.grpc-plugin and mcpplibs.grpcgen.