fix(protobuf): protoc 目标不声明在 windows;并让本 PR 不再触发全量 workspace

CI 暴露了两件独立的事。

── 1. windows:工具子构建失败,所以不在那里声明这个目标 ──────────────────
`workspace (windows)` 里 59 个成员挂了 3 个,其中一个是本 PR 新加的
protobuf-protoc。**不是 protobuf 的问题,也不是 flags 的问题** —— 同一次运行里
tests/examples/protobuf、protobuf-upb、protobuf-gzip 全部通过,用的是同一份
abseil + protobuf 源码,只不过是作为普通依赖构建的。只有**工具子构建**会死:

    error: building host tool 'compat.protobuf:protoc' failed
    error: cannot read 'obj/compat_abseil/…/absl/time/internal/test_util.cc.ddi'
           …/cctz/src/time_zone_posix.cc.ddi、…/cctz/src/zone_info_source.cc.ddi

**不是路径长度。** MAX_PATH 是最顺手的猜测,而且是错的:这三个相对路径分别是
31 / 46 / 47 字符,而同一个子构建里
`absl/container/internal/hashtablez_sampler_force_weak_definition.cc`(67 字符)
编得好好的。子构建内层 ninja 的输出是被汇总过的,真正的 scan 报错没进日志,
**原因未知**,也没有 windows 机器可复现。

在一个建不出来的平台上声明这个目标,等于把一个没有解释的失败甩给用户。所以
windows 平台块里放一份只含 `protobuf` 的 `targets`(平台块的 targets 覆盖顶层,
compat.vulkan 早就在用这个机制),等有 windows 环境查清楚再放开。

成员也随之按 `[target.'cfg(os)']` 分平台:linux/macOS 要 `tools = ["protoc"]`,
windows 只要运行时;build.mcpp 在 windows 上直接返回,tests/codegen.cpp 编成一条
**显式 skip** —— 一个什么都没验证却绿着的测试比红的更糟。

── 2. 还原 index.toml:它让 CI 跑全量 workspace 并超时 ────────────────────
成员选择把 `index.toml` 归到「未分类改动」→ `MEMBERS=__ALL__` → 59 个成员全建。
linux leg 因此**恰好跑满 150 分钟 timeout 被取消**(09:04:17 → 11:34:34),
其间每一条测试都是通过的。macOS 83 分钟侥幸跑完。

而我改它只是把 `latest_mcpp` 从 2026.8.3.3 抬到 2026.8.5.1 —— 一个**引擎里零消费者**
的提示字段(已 grep 确认:只解析、从不使用)。为一个纯装饰的字段换来 2.5 小时全量
构建并超时,不值。还原之后选择器只挑 protobuf 相关成员。

`min_mcpp` 本来就不动,那个判断没变。

Author: Sunrisepeak

index.toml

@@ -7,15 +7,5 @@
 # "floor first, new grammar after" rollout rule mechanically.
 [index]
 spec        = "1"
-#
-# These two move independently, and the 2026.8.5.1 CI pin is why. `min_mcpp` is
-# a GATE — an older client that fails it cannot open this index at all
-# (mcpp#349), so it moves only when a descriptor genuinely stops being readable
-# by the older grammar. Exposing compat.protobuf's `protoc` target did not do
-# that: 2026.8.3.3 still parses the descriptor with an empty `unknown_keys`.
-# What needs 2026.8.5.1 is the CONSUMER spelling `tools = [...]`, which lives
-# in a consumer's own mcpp.toml — including this repo's
-# tests/examples/protobuf-protoc, hence the CI pin. `latest_mcpp` is an
-# advisory hint with no gate behaviour, and tracks what CI validates against.
 min_mcpp    = "2026.8.3.3"
-latest_mcpp = "2026.8.5.1"
+latest_mcpp = "2026.8.3.3"

pkgs/c/compat.protobuf.lua

@@ -501,6 +501,35 @@ package = {
             -- here each package carries its own compile flags, so it has to be
             -- stated. No extra import libs: -ladvapi32 arrives with abseil.
             cxxflags = { "-DNOMINMAX", "-DWIN32_LEAN_AND_MEAN", "-D_CRT_SECURE_NO_WARNINGS" },
+
+            -- NO `protoc` TARGET ON WINDOWS — a platform `targets` replaces the
+            -- top-level one, so this drops the tool while keeping the library.
+            --
+            -- Not a protobuf problem and not a flags problem: the tool SUB-BUILD
+            -- fails there. In the same CI run, tests/examples/protobuf,
+            -- protobuf-upb and protobuf-gzip all pass on windows — the very same
+            -- abseil + protobuf sources, built as an ordinary dependency. Only
+            -- the sub-build dies, and only on three abseil TUs whose `.ddi` scan
+            -- outputs never appear:
+            --
+            --   error: building host tool 'compat.protobuf:protoc' failed
+            --   error: cannot read 'obj/compat_abseil/…/absl/time/internal/test_util.cc.ddi'
+            --   …/cctz/src/time_zone_posix.cc.ddi, …/cctz/src/zone_info_source.cc.ddi
+            --
+            -- It is NOT path length (MAX_PATH was the obvious guess and it is
+            -- wrong: those three relative paths are 31/46/47 chars, while
+            -- absl/container/internal/hashtablez_sampler_force_weak_definition.cc
+            -- at 67 compiles fine in the same sub-build). The sub-build's inner
+            -- ninja output is summarized, so the underlying scan error is not in
+            -- the log and the cause is UNKNOWN.
+            --
+            -- Declaring the target on a platform where it cannot be built would
+            -- hand users a failure with no explanation. Left off until the
+            -- sub-build issue is diagnosed on a windows host; nothing else about
+            -- this descriptor is windows-gated.
+            targets = {
+                ["protobuf"] = { kind = "lib" },
+            },
         },
     },
 }

tests/examples/protobuf-protoc/build.mcpp

@@ -29,6 +29,11 @@ static std::string well_known_types_dir() {
 }
 
 int main() {
+    // No `protoc` target on windows (see the descriptor's windows block), so
+    // there is nothing to declare and no include dir to add. Returning 0 keeps
+    // the member building; tests/codegen.cpp compiles to a visible skip.
+    if (std::string(mcpp::target_os()) == "windows") return 0;
+
     const std::string root = mcpp::manifest_dir();
     const std::string out  = mcpp::out_dir();
 

tests/examples/protobuf-protoc/mcpp.toml

@@ -9,15 +9,29 @@
 # generated-code ABI, and a mismatch there is a runtime failure, not a build
 # error. Here it is not expressible: `tools = ["protoc"]` makes the tool's
 # version the dependency's version.
+#
+# WINDOWS: linux + macOS only, matching the descriptor — compat.protobuf does
+# not declare the `protoc` target on windows, because the tool sub-build fails
+# there for reasons not yet diagnosed (see the comment in the descriptor's
+# windows block). The dependency below is therefore per-OS, and tests/codegen.cpp
+# compiles to a visible skip on windows rather than a test that silently proves
+# nothing.
 [package]
 name     = "protobuf-protoc-tests"
 version  = "0.1.0"
 standard = "c++23"
 
-[dependencies.compat]
 # One dependency, two roles: `features` shapes what gets LINKED (the runtime),
 # `tools` asks for a host binary out of the same package. `protoc` pulls in
 # libprotoc's 138 TUs and needs `upb` for the upb generator's runtime — the
 # descriptor's `required_features` states that, so asking for the tool is
 # enough and this manifest does not have to know it.
+[target.'cfg(linux)'.dependencies.compat]
+protobuf = { version = "35.1", tools = ["protoc"] }
+
+[target.'cfg(macos)'.dependencies.compat]
 protobuf = { version = "35.1", tools = ["protoc"] }
+
+# The runtime alone, so the member still builds and links something real here.
+[target.'cfg(windows)'.dependencies.compat]
+protobuf = "35.1"

tests/examples/protobuf-protoc/tests/codegen.cpp

@@ -20,6 +20,16 @@
 #include <cstdio>
 #include <string>
 
+// compat.protobuf declares no `protoc` target on windows, so nothing was
+// generated and there is nothing to assert. A loud skip beats a test that
+// passes without exercising anything.
+#ifdef _WIN32
+int main() {
+    std::puts("skipped: compat.protobuf has no protoc target on windows");
+    return 0;
+}
+#else
+
 #include "google/protobuf/util/time_util.h"
 
 #include "inventory.pb.h"
@@ -106,3 +116,5 @@ int main() {
     std::puts("protoc-generated code round-trips against the linked runtime");
     return 0;
 }
+
+#endif  // _WIN32