linux编译有警告怎么编译通过,Linux上 处理有成千编译警告的项目

* 打开最高级别的编译警告选项

* 打开警告视同错误的选项

这两点是基本常识, 被人说到懒得说, 懒得听. 但现实中, 往往接手这样的项目. 理论与实践之间的差距, 在实践中比在理论中要大得多.

如果接手时已经面对成千的警告, 以上两条就别想了, 你也不能指望哪个负责任的程序员会对自己引入的编译警告认真处理, 因为他根本没机会看到哪些是他新引入的. 这种情况下, 你也有个很好的借口, 可以项目在仅仅这一个方面一烂再烂地腐朽下去. 因为最初的烂摊子不是你造成的. 此人往往已经离职, 或许还在面试新工作时把你眼下接手的项目作为重要业绩介绍给新的雇主.

集中一次性销毁所有警告, 并非不可能.

在VC 2008中做过一次, 10万行C++代码.

现在在linux下, 被迫又要做一次. 把这个过程记下来, 有几个要点还是值得注意的.

要求: 100% 保证不引入新的bug.

1. 做一次干净的build. 捕获所有的编译输出, 包括错误输出, 并把该目录备份一下

make all 2>&1 | tee make.log

2. 用grep 过滤出make.log 中所有的警告信息

3. 对警告信息进行分类, 用sort

对gcc 的警告信息略加分析, 可知, 对于如变量定义了未使用这种情况, 警告信息中会用'variable_name'这种形式嵌入一些与具体符号名有关的信息. 要用sort进行排序, 就得忽略这些信息. 我的办法是:

先给每行用数字递增编号

:%s#^#\=line('.') .  ' '

然后把所有的'...' 都替换成'', 这样所有的同类警告信息就一致了.

然后以sort -t: -k4 -u 排序, 相信这一命令的输出结果会给你带来信心: 因为警告总数虽多, 但所属类别往往有限, 我眼下