chore: 三个包归到正确的命名空间(grpc:grpc / grpc:grpc-plugin / mcpplibs:grpcgen)

[Sunrisepeak]

判据

命名空间说的是这个库是谁的,不是谁打的包。

包	代码是谁的	证据	命名空间
grpc	上游 grpc/grpc	vendored src/ + include/	grpc
grpc-plugin	上游 src/compiler/*	每个文件都是 Copyright 2015 gRPC authors,Apache-2.0	grpc
grpcgen	本仓库自己写的	rules/src/grpcgen.cppm,163 行,上游没有对应物	mcpplibs

mcpplibs 是 mcpp 的默认命名空间(kDefaultNamespace = "mcpplibs"),不是"上游是谁"的答案。索引里 nlohmann.json、fmtlib.fmt、chriskohlhoff.asio、godotengine.godot-cpp-m 早就按上游 org 命名。

最能说明问题的是 godotengine.godot-cpp-m:它的 tarball 同样归 mcpplibs 所有、同样是上游之上的 module 层 —— 形态与 mcpplibs.imgui 完全相同,命名空间却相反。这条规则从来没有被定下来过,是逐 PR 决定的。

版本号不动

1.83.0 本来就与上游 gRPC 对齐,而这正是同一条规范的另一半要求。索引里其余几个包(imgui@0.0.6 包的是 ImGui 1.92.8、opencv@0.0.10 包的是 OpenCV 5.0.0)才是需要修的,另行处理。

已核实的代价

src/pm/dep_spec.cppm:

// Bare `gtest = "1.15.2"` becomes `(mcpplibs, gtest)`.
// `compat` is the ONE non-default namespace that an unqualified name reaches.
inline constexpr std::string_view kDefaultNamespace = "mcpplibs";

裸名梯级是 (mcpplibs, X) → (compat, X) → (∅, X),其他命名空间裸名一律够不到。所以:

[dependencies]
grpc.grpc        = "1.83.0"                                              # 要限定
grpc.grpc-plugin = { version = "1.83.0", tools = ["grpc_cpp_plugin"] }   # 要限定
grpcgen          = { version = "1.83.0", host-module = true }            # 默认 ns,可裸写
compat.protobuf  = { version = "35.1",   tools = ["protoc"] }

我考虑过给 mcpp 加一条可配置的裸名搜索路径(dep_spec.cppm 的注释确实指向这个方向),结论是不加:用户既然都要声明命名空间了,grpc.grpc = "1.83.0" 比"声明一条搜索路径 + 再写裸名"更短,而且把「这是谁的库」写进了依赖声明本身。

改动面

README(两份)、templates/greeter/mcpp.toml.in、设计文档。examples/ 用的是 path 依赖,不涉及命名空间;template-matches-example 只比对 build.mcpp,本次未触及。

索引侧的三个描述符在 mcpp-index 另开 PR,需要本 PR 合入后的新 tag(已发布的 v1.83.0 归档里没有 plugin/ 与 rules/,而索引对它的 sha256 已生效,移动 tag 会废掉它)。