feat: 一条依赖 + 一行 build.mcpp —— codegen 工具链由本包交给用户

[Sunrisepeak]

需要 mcpp 2026.8.6.2(已发布)。

使用者侧

-[dependencies.grpc]
-grpc        = "1.83.0"
-grpc-plugin = { version = "1.83.0", tools = ["grpc_cpp_plugin"] }
-[dependencies.mcpplibs]
-grpcgen     = { version = "1.83.0", host-module = true }
-[dependencies.compat]
-protobuf    = { version = "35.1", tools = ["protoc"] }
+[dependencies.grpc]
+grpc = { version = "1.83.0", features = ["codegen"] }

-int main() { return grpcgen::generate({"helloworld"}) ? 0 : 1; }
+int main() { return grpcgen::generate_all() ? 0 : 1; }

后三条依赖此前全是为了 codegen,并且要求用户知道「gRPC 的代码生成需要 protobuf 的 protoc」——那是本包的知识。新增一个 .proto 现在只是往 proto/ 里放一个文件,没有需要同步维护的清单。

靠什么成立

两处引擎能力,都在 mcpp 2026.8.6.2(mcpp#359):

• reexport = true —— [feature-deps.codegen] 把 protoc、grpc_cpp_plugin 与 grpcgen 规则模块交给消费者。默认关闭:protoc 会拖进 libprotoc 约 157 个额外 TU,只链接 gRPC 的项目不该为它付钱。
• rerun_if_changed_glob —— generate_all() 才是安全的。在此之前扫目录结构性不安全:新增一个 .proto 不改变任何已声明文件的哈希,build.mcpp 不重跑,新文件静默不生成(实测 Finished dev in 0.01s、产物 0 个)。这正是本仓库当初选择显式列表的原因。

顺带,[feature-deps.codegen] 往已经无条件声明的 compat.protobuf 那条边上追加 tools + reexport,这在 mcpp 侧也是本次才成立的(此前 try_emplace 会把 feature 的 spec 整个丢掉)。挪到无条件条目上不可行——那会让每个 grpc 消费者都构建 protoc。

本仓库内的验证

examples/greeter 保留 path 依赖(它要测的是工作树,而 feature 里写的是索引版本),但同样改用 generate_all(),于是 glob 路径在本仓库 CI 里有覆盖。已在本机跑通:

Compiling greeter v0.1.0 (.)  →  helloworld: OK

然后往 proto/ 里丢一个 extra.proto、不改 build.mcpp 一个字,重新构建即产出 extra.pb.cc/.h 与 extra.grpc.pb.cc/.h 并编进目标。

一条依赖的形态由已发布索引验证(见下)。

其他

• generate() 的入参从 initializer_list<const char*> 改为 vector<string>,generate_all() 复用它;两者都会为嵌套 .proto 建好输出子目录——protoc 会按相对路径写,但不建中间目录,平铺的 proto/ 从不暴露这一点。
• 模板、README(中英)、MCPP_VERSION 下限 2026.8.5.2 → 2026.8.6.2。

合入后

发 v1.83.0-3,mcpp-index 三个描述符换 url + sha256,并新增 tests/examples/grpc-codegen 成员——它是唯一能证明「reexport 真的经由已发布索引到达消费者」的地方,顺便让 grpc-module 里那句「gRPC's codegen needs host tools mcpp cannot hand a consumer」不再过时。