bump(grpc): 三个描述符指向 v1.83.0-3 —— codegen 工具链由 grpc 包交给用户 - #172
Merged
Conversation
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)。先发布,
再验证。
Member
Author
|
失败成员是 openssl 经自己的 Perl 验证本 PR 的分片全绿:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
grpc-m v1.83.0-3 起,gRPC 的使用者写一条依赖而不是四条:
「gRPC 的代码生成需要 protobuf 的 protoc」是 grpc 包的知识,不是用户的;新增一个
.proto现在只是往proto/里放一个文件。靠 mcpp 2026.8.6.2 的两处能力(mcpp#359):
reexport = true让[feature-deps.codegen]把工具与规则模块交给消费者;rerun_if_changed_glob让generate_all()安全 —— 在此之前扫目录结构性不安全,新增.proto不改变任何已声明文件的哈希,程序不重跑,新文件静默不生成。CI 的
MCPP_VERSION同步提到 2026.8.6.2。index.toml的min_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。