当出现问题时应该怎样做
首先，不要恐慌。研发人员在编写出一个完整的版本之前，可能需要解决很多怪异的 make 问题。隐式规则、没想到的变量替换连同嵌入式 shell 脚本中的语法错误，都可能会引发这种痛苦的享受。
此时需要仔细阅读错误消息。这是 make 自己产生的消息么？还是 make 所调用的东西产生的消息？假如有一个嵌套的编译，可能会需要通过对一组错误消息来仔细进行分析，才能找到确切的错误。
假如一个程式没有找到，首先要检查他是否已安装了。假如已安装了，那么就要检查路径配置是否正确；有些研发人员的习惯是在 makefile 中使用绝对路径，这在其他系统上可能会失败。假如将某些东西安装到 /opt 中，而 makefile 引用的却是 /usr/local/bin，那么编译就会失败。此时就需要修改路径的配置。
检查系统时钟；更重要的是，要检查编译树中文档的日期、系统中其他文档的日期连同系统的时钟。在面临输入数据的时间顺序不一致的情况时，make 的行为可能是无害的，也可能是不现实的。假如碰到了时钟问题（例如有些 “新” 文档被标记成 1970 年的），那么就需要修整这个问题了。 “touch” 工具是个很好的帮手。在时钟问题中产生的错误消息通常都不太明显。
假如看到的错误消息显示有一些语法错误，或有很多变量没有配置，或配置得不正确，那么能够尝试试验一下其他版本的 make；举例来说，有些程式在使用 gmake 编译时会产生一些很含糊的错误，而使用 smake 时就能很好地进行编译。有些很怪异的错误会说明正在使用 GNU make 来运行一个 Berkeley 的 makefile，反之亦然。Linux 特有的程式通常会假设使用 GNU make，使用其他 make 工具可能会碰到莫名其妙的错误，有些甚至在文档中都没有任何提示。
调试标记可能会很有用。对于 GNU make ，-d 标记会提供大量的信息，其中有些是很有用的。对于 Berkeley make ，-d 标记有一组标记；-d A 表示完整的集合，或能够使用其中的一些子集；举例来说，-d vx 会给出有关变量赋值（v）的调试信息，这会导致通过 sh -x 来运行任何的命令，这样 shell 就会精确地回显自己接收到的命令。-n 调试标记会导致 make 打印他认为需要做的事情的一个列表；这并不总是正确的，但是通常能够为思考哪些地方出现了问题而提供一些思路。
在调试 makefile 时，目标是找到 make 正在试图编译什么东西，连同他认为哪些命令能够用来编译。假如 make 使用了正确的命令，但命令却出现了故障，那么这可能意味着完成了 make 调试 —— 但也许并不完全是。举例来说，假如试图编译程式时由于存在无法解析的符号而失败了，那么就可能是编译过程前面某个步骤出现了问题！假如不能定位命令中哪儿出现了问题，并且他看起来应该正常工作，那么很可能是 make 前面创建的某个文档没有被正确创建。
文档
通常情况下， GNU make 的主要文档都没有以 man 格式提供，这一点很不幸；我们只好使用 info 系统，而且不能运行 man make 来查找有关的信息。但是这些文档还是很齐全的。
要找到有关任何实现都能支持的特性的一个 “安全子集” 的文档很难。Berkeley 和 GNU make 文档在描述扩展时都试图提及这个问题，但是多做些测试总是个好事，这样就不会全靠猜测去定义每个 make 工具的确切界限。
经过一段时间的发展，BSD 系列之间的微小偏移已在 make 实现之间产生了一些差异。在三者之中，NetBSD 是 make 在其他系统上支持最为广泛的；NetBSD pkgsrc 系统现在还在其他平台上使用，他就严重依赖于 NetBSD 的 make 实现。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
