分类： LINUX
2009-02-10 09:27:48
在某些Makefile中，可能会有mkdep命令，但是通常情况下mkdep并没有安装，make时会提示错误。解决办法是在Ubuntu的终端中输入mkdep，然后按照提示在线安装mkdep，再执行make，问题解决。
mkdep 可算是 make 的辅助工具。
通常，我们在 Makefile 里写下 source code 和产生出来的 binary code 的依存规则。当然也有不是 binary code 的场合，比方说用 Makefile 来产生 doxygen 或 latex 文件。原则是，有个 source -> target 的相关性。
mkdep 就我个人的看法，是比较特化给 C 语言用的。它接受原本给 cc 的 CFLAGS 和 SRCS 参数，藉由偷看 cc 的参数，找出 .c 檔和 .h 檔的相依性。它作了一部份 cpp parse 原始文件的前置指令的工作，但不多动原始档，而是将用到的 header files 记录在 .depend 里，提供给 make 作为编译程序时的额外参考。
source -> target 的相依性，是比较显而易见的。有什么样的原始码，就产生出什么样的 binary code。但对于 header files 来说就不那么明显。对于只用到系统一般提供函式库的场合，header files 可能是永远不会变的，因此不太需要考虑到这个问题。但如果是同时在修改 header files, 或是它会常常更新，那么有个程序自动找出它的相依性，就很重要了。当 header files 改变时自动重新编译，不仅仅是像 Makefile 一样自动检查相依性，以减少编译的时间而已，也能减少因为 header files 版本不同，而遇到的奇奇怪怪问题。尤其是在抽象化得比较完整的 case, header files 可能是一层包一层，让追问题更加困难。
有经验写过或用过 Makefile (也就是使用 'make' 这个指令)的人都知道，如果Makefile 里的相依性规则没有写好，有时会遇到明明某个原始档更新了，却没有重新编译，以致于程序跑不出想要的结果。如果Makefile 里有定义 clean: 或 distclean: 这类的 targets, 整个重新编译过也许可以解决，但这会多花许多重复编译的时间，而且你还是不知道问题是谁造成的。
同样的问题发生在更隐诲不明的 header files 时，就更麻烦了。因为最明确的 #include 是写在 .c 档里，不是 Makefile 。哪一天别的小组或是供货商更新了他们提供给你的函式库 header files, 而没有提醒你时，你就等着遇到各种奇奇怪怪的问题了。
因为这是在 header files 会更新时，才能显现出它的好处，一般只是用现成函式库开发程序，或是只编译一次原始码，产出程序来用，而不管程序到底写什么， 或到底需要改什么的人来说，比较体会不到。但在同时修改函式库或 header files 的人，能利用它就会很方便地减少许多问题和重复编译的时间。所以现在能想到比较明显的例子，就是在 FreeBSD 或 Linux 编译 kernel 时。
FreeBSD 编译 kernel 的标准用法，是 make depend all install。 Linux 是 make dep image 。这 depend 或 dep target, 就是在执行 mkdep 。当然后来它们的编译步骤又被包装得更容易，也许第一眼看不到这些 make 指令，但跟着Makefile 追踪下去就会发现。
