如何在 MSBuild 中自定义 C++ 编译器错误消息？

Posted 2023-02-22

【中文标题】如何在 MSBuild 中自定义 C++ 编译器错误消息？

【英文标题】：How to customize C++ compiler error message(s) in MSBuild?

【发布时间】：2014-08-01 17:08:03

【问题描述】：

是否可以影响 MSBuild 格式化和报告作为构建 C++ 项目的一部分运行的 CL.EXE 输出的准确方式？

从命令行和 Visual Studio 运行时它们实际上有所不同：

Command-line:  file(line): error message [project]
Visual Studio: file(line): error message

这似乎是一个小细节，但是我真的非常需要在 Visual Studio 构建中显示 [项目]，因为我正在触发先决条件的构建，并且不想将它们的错误与父项目的错误混为一谈.

我尝试伪造 $(BuildingInsideVisualStudio) 并观察正在传递给 MSBuild 的任何属性，但无济于事，并且无法将命令行错误消息样式导入 VS。强制它的一种方法是使用 任务而不是 但在几乎所有可以想象的方式中都不需要生成单独的构建过程。有什么方法可以和平说服它吗？即使 $(BuildingInsideVisualStudio) 被覆盖为 true 或 false，它似乎也不会影响错误输出的样式。奇怪的。也许 Visual Studio 会拦截并重新格式化消息？

感谢您的帮助。

【问题讨论】：

可能 VS 使用自定义记录器 - 不确定是否可以替换它

也让我得出这个结论。我希望有办法扩展它。

一种可能的“穷人”方法是启用日志记录到 VS 中的文件，然后在构建完成后调用自定义任务来解析日志文件并获取错误/项目构建开始事件，然后输出它们再次使用 LogError 但附加了项目信息

【参考方案1】：

MSBuild 提供了非常好的可扩展性。将任何 *.targets 文件放在$(VCTargetsPath)\Platforms\$(Platform)\ImportBefore\ 下，其中包含要在标准处理之前加载的自定义目标。

在下面创建一个名为custom.cpp.win32.targets的文件：

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Win32\ImportBefore\

将以下内容复制到custom.cpp.win32.targets。这将在调用 cl.exe 之前打印项目的完整路径：

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>
  <BeforeClCompileTargets>
     BeforeClCompileCustom;
   $(BeforeClCompileTargets);
  </BeforeClCompileTargets> 
</PropertyGroup>

<Target Name="BeforeClCompileCustom">
    <Message Importance="high" 
             Text="Building '$(ProjectName)' - $(Platform)|$(Configuration) [$(MSBuildProjectFullPath)]" />
</Target>

【讨论】：

感谢您的提示。但是，我想自定义 cl.exe 的实际输出，以便 VS 的错误窗口中显示的任何错误也包括原始项目，就像 MSBuild 的命令行版本似乎一样。您知道如何自定义 MSBuild（从 VS 内部运行时）如何呈现 cl.exe（警告/错误）的输出吗？

VS Error List 窗格就是为此而设计的。单击输出窗格中的错误也将打开源文件。我认为没有任何理由改变这种行为。没关系。

好的，让我详细说明一下。如果您将 任务作为项目编译的一部分运行，则 if 将显示在运行它的项目的名称下，无论您是否实际上正在编译完全不同的项目文件（因为您需要它作为先决条件而不是您的解决方案的一部分）或不是。更改错误输出的原因是我添加了遇到的错误实际上在不同项目中的信息。虽然点击它确实导航到源文件，但不点击，无法知道哪个项目负责（显示“父”）。

并回答一个可能的后续问题“我为什么不简单地使用项目到项目的引用”：我们有超过 300 个项目参与我们的构建，所以将它们放在一起，在一种解决方案是简单的混乱，不能进一步发展。我编写了一个构建脚本，即使它们在不同的解决方案中，它也能正确理解和构建它们的依赖关系，最后一英里只是 Visual Studio 报告遇到的任何错误，因为它是在 触发 pre-必要的 让开发人员感到困惑。但是添加一个简单的“在项目 XXX”...