为什么使用 BullsEye 编译器编译项目？答案

【问题标题】：Why are projects compiled with BullsEye compiler?为什么使用 BullsEye 编译器编译项目？
【发布时间】：2014-03-30 08:52:01
【问题描述】：

我们在所有 TeamCity 代理上都安装了 BullsEye Coverage，并且有一个夜间脚本可以打开 BullsEye、重建我的项目、运行单元测试然后关闭 BullsEye。 BullsEye bin 目录不在机器的路径中，我的脚本在运行之前添加了路径。（该路径仅作为该会话的脚本的一部分添加，并没有为整台机器永久设置）。

最近我在 TeamCity 构建日志中注意到所有项目（常规项目，而不仅仅是配置为运行覆盖的项目）都使用 BullsEye 编译器。这是日志中的一个示例：

[11:29:38] [bsii_algorithms\build\vc10\bsii_algorithms.vcxproj] ClCompile (8s)
[11:29:38] [ClCompile] CL (3s)
[11:29:38] [CL] C:\Program Files (x86)\BullseyeCoverage\bin\CL.exe /c /I..\..\include /I..\..\..\bsii_common\include ...

此外，其中一个项目的构建速度非常慢。具体来说，“ResolveProjectReferences”大约需要 20 分钟。我在网上读到这可能发生，因为某种分析已打开。所以我使用 TeamCity 用户登录服务器并再次关闭 BullsEye。但这没有帮助。

所以我的问题是：

是否可以使用 BullsEye 文件夹中的编译器编译所有内容，即使 BullsEye 不在计算机路径中？
如何配置机器以便只有覆盖脚本使用 BullsEye 编译器？
这可能是构建需要很长时间的原因吗？

谢谢！

【问题讨论】：

标签： teamcity bullseye

【解决方案1】：

请注意，bullseye 已全局启用（通过注册表？），因此与您的覆盖构建并行运行的任何构建都会发现自己（部分）被检测。出于这个原因，我们在他们自己的机器上运行我们的覆盖构建。

【讨论】：

你确定吗？我们通过打开覆盖范围的批处理脚本运行构建（使用 cov01 --on）。这不只适用于那个批处理脚本吗？
@dina 实际上没有。这是全局变化，而不是每个脚本甚至每个 shell / 终端会话
我可以确认这一点。正如我刚刚发现的那样，在具有多个并发运行器的 Gitlab 管道中使用 Bullseye 是一场噩梦。 $covfile 变量也是全局变量，因此并发运行者输入竞争条件来命名文件。

【解决方案2】：

是的，预计会使用 Bullseye 文件夹中的编译器。这就是 Bullseye 覆盖工具的工作方式，通过使用特殊的“检测版本”拦截实际编译器。最终，Visual Studio 编译器在底层被调用。

如果您删除脚本启用 Bullseye 的步骤（通过调用“cov01 -1”），那么 Bullseye 编译器应该只传递到 Visual Studio 编译器，您将不会有代码覆盖。

我不确定时间问题。

VS Bullseye 文档的链接：here

【讨论】：