为什么MSBuild会将.tlog文件生成到CMakeFiles / CompilerIdC中，如何让它停止？

Posted 2021-03-27

我有一个CMake项目，我的一个构建在Visual Studio上，使用MSBuild，在TeamCity构建服务器上。

我所看到的是在运行git clean -f -d -x时经常出现故障（TeamCity在初始化构建时自己做了一步，作为源检查的一部分）。它失败的原因是因为.tlog文件被生成到我的CMake构建文件夹中 - 进入CMake的内部CompilerIdC项目，CMake用它来识别本地C编译器。

什么是qazxsw poi文件，以及触发创建的内容？我还没有找到这方面的文档。

我不明白为什么他们在CMake运行后出现，并且构建已经完成。我特别不明白为什么在所有.tlog的源文件和项目文件被删除后超过十五分钟创建它们。

细节

这些文件正在生成CompilerIdC。他们都是${CMAKE_BUILD_DIR}/CMakeFiles/3.5.2/CompilerIdC/Debug/CompilerIdC.tlog的形式。

这是在link-VCTIP.(read|write|delete).*.tlog上失败的构建文件夹的状态，并在08:41停止（当前截至09:30）：

git clean

构建日志如下所示：

-rw-r--r-- 1 CI 197121  570 Jun 28 08:57 link-VCTIP.delete.1.tlog
-rw-r--r-- 1 CI 197121 1422 Jun 28 08:57 link-VCTIP.delete.26.tlog
-rw-r--r-- 1 CI 197121 7062 Jun 28 08:57 link-VCTIP.read.1.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:50 link-VCTIP.read.103.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:55 link-VCTIP.read.120.tlog
-rw-r--r-- 1 CI 197121  418 Jun 28 08:57 link-VCTIP.read.26.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.27.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.28.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.29.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:45 link-VCTIP.read.87.tlog
-rw-r--r-- 1 CI 197121  600 Jun 28 08:57 link-VCTIP.write.1.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.write.26.tlog

版本信息

我正在使用的工具是：

• MSBuild 14.0
• CMake 3.5.2
• TeamCity Professional 9.1.7

答案

什么是[08:39:58][VCS Root: MyVCS] [D:TeamCityuildAgentwork58a2d5637a76fb3e]: "C:Program FilesGitingit.exe" clean -f -d -x [08:41:26][VCS Root: MyVCS] warning: failed to remove build/Windows-x64-Release/: Directory not empty [08:41:27] [Updating sources] Failed to perform checkout on agent: '"C:Program FilesGitingit.exe" clean -f -d -x' command failed. stdout: Removing Artifacts/x64/ <snip> Removing build/Windows-x64-Release/CMakeFiles <snip> stderr: warning: failed to remove build/Windows-x64-Release/: Directory not empty 文件？

它们由MSBuild的文件跟踪器输出，后者包装Visual C ++构建可执行文件（例如.tlog和cl.exe）以跟踪它写入和读取的文件。它将这些文件路径记录在link.exe文件中的中间目录中，并依赖于这些文件路径来定义如何构建增量构建。

（来源：.tlog，Sayed Hashimi和William Bartholomew。）

什么触发了他们的创作

任何使用MSBuild都可以触发Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build文件的创建或更新。

为什么这些文件出现得这么晚？

编写.tlog文件的过程之一是.tlog。 2018年3月，微软工程师Ian Bearman（VC ++遥测的所有者）vctip.exe：

这个小应用程序是在构建期间运行的后台进程，允许VC ++工具与VS遥测服务（也称为VS体验改善计划）进行通信。应用程序在构建后保持运行，以防立即启动另一个构建以帮助加快编译速度。

我知道目前的超时（接近15分钟）太长了。

因此，答案是：即使在构建完成后，后台进程仍然存在，在这种情况下，即使删除了所有相关文件，并继续尝试将遥测文件写入其目录。

我该如何解决这个问题？

Bearman建议explained：

1. 升级Visual Studio。 即将发布的Visual Studio版本（从VS 2017 15.7开始，现在处于预览状态）将缩短在最后一次构建后运行至15秒的时间。希望这能解决您在此计划中保持运行所遇到的任何问题。

（我没有尝试升级，所以我无法确认这解决了问题。我也非常感兴趣地注意two solutions非常相同的问题，an earlier bug report回答说最近的更新解决了这个问题。）

2. 手动杀死a promise in March 2018。

在此期间，要解决此问题，请随时手动终止vctip.exe。您可以使用Windows命令vctip.exe立即停止它。这样做总是安全的，不用担心数据丢失或损坏。

在我自己特定的TeamCity案例中，在MSBuild完成后，很容易添加为构建配置的额外构建步骤 - 运行脚本：

taskkill /IM vctip.exe

请注意，此解决方案确实对您的构建系统做出了某些假设，例如：它没有一次运行多个构建。并且一定要记录好这一点，因为稍后确定它来自哪里将是一个头脑...

另一答案

可能这里的实际根本原因修复项可能是：

taskkill /IM vctip.exe /f >nul 2>&1

MSBuild和/ nodeReuse：false

如果在构建期间调用MSBuild，请确保传递参数/ nodeReuse：false（短格式/ nr：false）。否则MSBuild进程将在构建完成后继续运行。由于预期可能的后续构建，该过程保持一段时间。

MSBuild的此功能可能会干扰删除或移动目录的尝试 - 由于与MSBuild进程的工作目录冲突。

MSBuild和Visual Studio Build任务已经将/ nr：false添加到传递给MSBuild的参数中。但是，如果从自己的脚本调用MSBuild，则需要指定参数。

？ （如果这里实际上是正确的处理，那将是一个比需要随机杀死随机非自有进程的不确定性 - 解决方法更精确的处理方法）

请注意，如果这是根本原因，那么可能需要在CMake生成器源代码（msbuild调用[，有条件/智能]）中修复它...

旁注：我考虑保持后台进程运行的机制 - 喘气！ - 以相当终生不精确/不受控制的方式进行遥测目的（占用目录，......），这对于所谓的精确控制/执行/确定性构建处理来说是一个相当可疑的[/攻击性]事物。