在后续构建中保存并重新打印成功编译文件的警告? [英] Save and reprint warnings for successfully-compiled files on subsequent builds?

问题描述

在重复构建项目时，当翻译单元中有警告但没有错误时，通常不会重新编译主源文件.

When repeatedly building a project, when there are warnings but no errors in a translation unit, the main source file is typically not recompiled.

这会导致难以解决错误和警告，以尝试在没有警告的情况下构建项目.通常，必须不断迭代构建，直到处理完所有错误，然后进行全面清理和构建以确保没有警告(以及确保先前完成的构建不是由剩余的构建工件造成的侥幸").

This can make it difficult to work through errors and warnings to attempt to get the project to build with no warnings. Typically one must keep iteratively building until all errors are taken care of, then do a full clean and build to ensure that there are no warnings (as well as to ensure that the previously-completed build wasn't a "fluke" caused by leftover build artifacts).

CMake(或其他一些实用程序，例如 Bash 脚本)有什么方法可以解析构建输出以获取警告，将它们保存在某个文本文件中，然后在后续构建中重新显示它们?

Is there any way with CMake (or some other utility such as a Bash script) to parse build output for warnings, save them in a text file somewhere, and then re-display them on subsequent builds?

对于加分，由于我正在对编译器输出进行着色，是否可以使用颜色控制字符保存警告并以相同的着色重新显示?

For bonus points, since I'm colorizing my compiler output, can warnings be saved with the color control-characters and re-displayed with the same colorization?

(如果重要的话，目前我只编译 C++，而且我通常使用 GCC 来编译.我选择的构建生成器是 Ninja，我编写了一些 Bash 脚本来包装所有我对 CMake 和 Ninja 的调用.)

(If it matters, at the moment I'm only compiling C++, and I'm typically using GCC to do so. My build generator of choice is Ninja, and I have some Bash scripts I've written that wrap all my calls to CMake and Ninja.)

推荐答案

我不是 bash 专家 - 所以下面的代码当然可以改进 - 但这里是一个带有 CMake/bash/gcc/ninja 应该给出我的基本想法:

I'm not a bash expert - so the following code can certainly be improved - but here is a working example with CMake/bash/gcc/ninja that should give the basic idea I had:

• 检测编译器是否在 stderr
上放置警告/错误
• 将其存储在<目标文件名>.warnings
• 在下一次构建开始前删除有警告的目标文件
• 编译器本身会再次输出警告(如果尚未修复)

CMakeLists.txt

cmake_minimum_required(VERSION 2.8)
project(CaptureWarnings CXX)

add_compile_options(-fdiagnostics-color=always -Wconversion)
configure_file(capture_warnings.sh.in ${CMAKE_BINARY_DIR}/capture_warnings.sh @ONLY)

file(WRITE foo.cc "int main() {
return 0.5;
}")
file(WRITE bar.cc "")

set_directory_properties(PROPERTIES 
    RULE_LAUNCH_COMPILE "bash ${CMAKE_BINARY_DIR}/capture_warnings.sh")

add_executable(MyExe foo.cc bar.cc)

capture_warnings.sh.in

#!/bin/bash

# shell script invoked with the following arguments
# $(CXX) $(CXX_DEFINES) $(CXX_FLAGS) -MMD -MT OBJ_FILE -MF DEP_FILE -o OBJ_FILE -c SRC_FILE

# extract parameters
OBJECT_FILE="${@: -3:1}"

# invoke compiler
set -o pipefail
$@ 2> ${OBJECT_FILE}.warnings
ERROR=${PIPESTATUS}

OUT=$(<${OBJECT_FILE}.warnings)

if ! [[ -z "$OUT" ]]; then
    # reprint the warning/error
    >&2 echo "${OUT}"
    echo "rm -f ${PWD}/${OBJECT_FILE}" >> @CMAKE_BINARY_DIR@/remove_obj_with_warnings.sh
else
    rm -f ${OBJECT_FILE}.warnings
fi

exit ${ERROR}

build.sh

#!/bin/bash

if ! [ -d build ]; then
    mkdir build
    cmake -H. -Bbuild -G "Ninja"
fi

if [ -f build/remove_obj_with_warnings.sh ]; then 
    sh ./build/remove_obj_with_warnings.sh
    rm build/remove_obj_with_warnings.sh
fi

cmake --build build

我认为在 remove_obj_with_warnings.sh 中收集要删除的文件比搜索 .warnings 文件要快.缺点是它可能包含已删除或尚不存在的文件(通过提供 rm -f 覆盖).

I thought collecting the files to be deleted in remove_obj_with_warnings.sh would be faster than grepping for the .warnings files. The disadvantage would be that it could contain files that are already deleted or not-yet-existing (covered by giving rm -f).

如果您将 remove_obj_with_warnings.sh 调用设为可选，则尤其如此.

Especially true if you make the remove_obj_with_warnings.sh call optional.

使用的参考:

1. 让 CMake 使用 gccfilter
2. 让 gcc 将相关文件名放入调试信息中
3. bash: 重定向(并附加)stdout 和 stderr 到文件和终端并获得正确的退出状态
4. 在 Bash 脚本中处理 gcc 警告和输出

这篇关于在后续构建中保存并重新打印成功编译文件的警告?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！