fix(link): 响应文件按行分隔,拆掉 link.exe 的单行 128 KiB 上限 (2026.8.5.3)

[speak-agent]

症状

mcpp-index 的 opencv-module / opencv-module-dnn 在 windows 上,编译完 795s / 1166s 之后死在链接:

D:/.../clang++.exe @bin/opencv_module.exe.rsp -o bin/opencv_module.exe ...
C:\Users\RUNNER~1\AppData\Local\Temp\response-f6f0f2.txt :
    fatal error LNK1170: line in command file contains 135135 or more characters

根因:第二道上限,一直没人碰到

一条链接边和操作系统之间有两道上限,而「改用响应文件」只拆掉了第一道:

	上限	状态
命令行	Windows CreateProcess 32 KiB;POSIX 下 ninja 用 sh -c "<整条命令>",整条命令是一个 argv 项 → MAX_ARG_STRLEN 128 KiB	#344 / PR#345 已拆
响应文件的单行长度	link.exe 128 KiB	本 PR

rspfile_content = $in 让 ninja 把所有对象写成一行。对象一多,行就超过 128 KiB。

修复

-  rspfile_content = $in
+  rspfile_content = $in_newline

ninja 用换行分隔。之后没有任何上限再随对象数增长。

全平台同一条规则形状,不需要按方言分支:GNU 与 LLVM 的响应文件解析把任何空白(含换行)当分隔符,而 link.exe / lib.exe 要的正是这种写法。

实测(25 个对象):

=== rsp 内容 ===
行数: 24  字节: 301
obj/main.o
obj/f9.o
obj/f8.o

测试

新增 e2e 190,两面都钉:

• 结构面 —— 生成的规则必须是 $in_newline,且不得再出现裸 $in;
• 可观测面 —— ninja -d keeprsp 保留下来的响应文件必须一行一个对象,最长行远低于 128 KiB。

只钉前者的话,ninja 哪天改了 $in_newline 的展开方式,测试仍会绿。结构断言已在 2026.8.5.2 上验证为红(那里是 rspfile_content = $in),不是空断言。

链接相关 e2e 全绿:28_target_static / 47_llvm_atomic_link / 86_llvm_hermetic_link / 07_static_library / 183_cross_no_relink / 190。

同一族的第四次

#274、#247、#344,再加本条。前三次的教训写的是「一条命令有多长,不该有人放在心上」;这次补上的是它的孪生兄弟:一行有多长同样不该。构建系统不该有一个「靠崩溃才发现」的工程规模上限,而这次的代价尤其刺眼 —— 20 分钟的编译全做完了,才在最后一步倒下。

配套

mcpp-index 侧会另开 PR:pin 到本版,并去掉 MCPP_BUILD_CACHE: local。那个开关是 #344 的临时规避(#344 已在 2026.8.3.4 修复),它让每个 workspace member 各自重编全部依赖 —— opencv 系每个 10~20 分钟,全量运行 2 小时以上。