Skip to content

bump(grpc): 三个描述符指向 v1.83.0-3 —— codegen 工具链由 grpc 包交给用户 - #172

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/grpc-codegen-one-dependency
Aug 6, 2026
Merged

bump(grpc): 三个描述符指向 v1.83.0-3 —— codegen 工具链由 grpc 包交给用户#172
Sunrisepeak merged 1 commit into
mainfrom
feat/grpc-codegen-one-dependency

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

grpc-m v1.83.0-3 起,gRPC 的使用者写一条依赖而不是四条:

-[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; }

「gRPC 的代码生成需要 protobuf 的 protoc」是 grpc 包的知识,不是用户的;新增一个 .proto 现在只是往 proto/ 里放一个文件。

靠 mcpp 2026.8.6.2 的两处能力(mcpp#359):reexport = true[feature-deps.codegen] 把工具与规则模块交给消费者;rerun_if_changed_globgenerate_all() 安全 —— 在此之前扫目录结构性不安全,新增 .proto 不改变任何已声明文件的哈希,程序不重跑,新文件静默不生成。

CI 的 MCPP_VERSION 同步提到 2026.8.6.2。

index.tomlmin_mcpp 不动

旧客户端仍能加载 grpc 的 manifest —— 2026.8.6.2 起不认识的依赖键降级而非让整份加载失败 —— 只是拿不到工具链,且 grpcgen 会明确说出缺什么。为一个包抬全局下限,正是 mcpp#349 修掉的那个错误。

tarball 核验

GitHub 与 GitCode 两端同为 9a0514a325e348fb013a89bb7b1acb9b41f42d5e9f3c92cee8be788e1e48d74f(4073680 字节)。CN 那份是本地 gtc 上传后回探下载重算得到的,不是读 sidecar,也不是只看状态码。

为什么 tests/examples/grpc-codegen 不在本 PR 里

那个成员要证明的正是「reexport 经由已发布索引到达消费者」。而在本 PR 的 CI 里,mcpplibs.grpcgen 仍会解析到线上的 -2(本仓库每个成员的 [indices] 只能重定向一个命名空间 —— mcpp#238 / xlings#374),那份 grpcgen 还没有 generate_all()。所以顺序只能是:先发布,再验证。成员随后单独开 PR。

grpc-m v1.83.0-3 起,使用者写一条依赖而不是四条:

    [dependencies.grpc]
    grpc = { version = "1.83.0", features = ["codegen"] }

    import mcpp; import grpcgen;
    int main() { return grpcgen::generate_all() ? 0 : 1; }

grpc 的 [feature-deps.codegen] 用 reexport = true 把 protoc、grpc_cpp_plugin
与 grpcgen 规则模块交给消费者;generate_all() 借 rerun_if_changed_glob 扫
proto/。两者都需要 mcpp 2026.8.6.2(mcpp#359),CI pin 同步提到该版本。

index.toml 的 min_mcpp **不动**。旧客户端仍能加载 grpc 的 manifest —— 2026.8.6.2
起不认识的依赖键降级而非让整份加载失败 —— 只是拿不到工具链,且 grpcgen 会明确
说出来。为一个包抬全局下限正是 mcpp#349 修掉的那个错误。

tarball 已核验:GitHub 与 GitCode 两端同为
9a0514a325e348fb013a89bb7b1acb9b41f42d5e9f3c92cee8be788e1e48d74f(4073680 字节),
CN 那份是本地上传后回探下载重算得到的,不是读 sidecar。

tests/examples/grpc-codegen 成员单独开 PR:它要证明的是「reexport 经由**已发布**
索引到达消费者」,而在本 PR 的 CI 里 mcpplibs.grpcgen 仍解析到线上的 -2(本仓库
的 [indices] 每个成员只能重定向一个命名空间 —— mcpp#238 / xlings#374)。先发布,
再验证。
@Sunrisepeak

Copy link
Copy Markdown
Member Author

workspace (linux 1/3)(linux 2/3) 红,根因与本 PR 无关,main 上同样红(run 31088396750,同样是这两个分片)。

失败成员是 openssl(以及依赖它的 curl):

crypto/aes/aes_ecb.c:10:10: fatal error: assert.h: No such file or directory
include/internal/common.h:14:11: fatal error: stdlib.h: No such file or directory

openssl 经自己的 Perl Configure + GNU make 直接调 cc,因此拿不到 mcpp 解析出的 sysroot flags;而 xim gcc 把构建机的 sysroot 烙进了二进制。compat.openssl.luacc_override() 已为 macOS 处理过同一类问题,其注释明写「on linux the xim gcc carries its own payload and is the right compiler to use」——坏掉的正是这个假设。根治在 xim-pkgindex(让 gcc 可重定位),不在本仓库。

验证本 PR 的分片全绿:

  • workspace (linux 0/3) — 含 grpc-module,即消费改动后描述符的成员
  • workspace (macos 0/1) — 单片,跑全部成员
  • windows 0/2 1/2lintselecttimings
  • mirror-cn-reachable — 独立够到了新的 CN URL,与我本地 gtc 上传后回探重算的 sha256 一致

@Sunrisepeak
Sunrisepeak merged commit 312e8b0 into main Aug 6, 2026
8 of 10 checks passed
@Sunrisepeak
Sunrisepeak deleted the feat/grpc-codegen-one-dependency branch August 6, 2026 12:39
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