奇怪的事情发生:
makefile 的想法是能够同时编译多个文件。如果您编辑其中一个文件,当您键入 时make
,唯一应该编译的文件就是已编辑的文件。
现在,由于某种原因,我的 makefile 决定停止识别文件何时更改。所以我必须:make clean
并且make
再次能够编译,这很荒谬,因为每次我必须编译大约需要 1 分钟。
任何想法为什么会发生这种情况?
我没有在我的makefile中添加任何东西;它只是突然开始这样做。
奇怪的事情发生:
makefile 的想法是能够同时编译多个文件。如果您编辑其中一个文件,当您键入 时make
,唯一应该编译的文件就是已编辑的文件。
现在,由于某种原因,我的 makefile 决定停止识别文件何时更改。所以我必须:make clean
并且make
再次能够编译,这很荒谬,因为每次我必须编译大约需要 1 分钟。
任何想法为什么会发生这种情况?
我没有在我的makefile中添加任何东西;它只是突然开始这样做。
发生了一些变化;除非有所改变,否则程序不会停止工作。困难在于弄清楚发生了什么变化。您可以随时输入:
rm file-that-changed.o
make
仅重建一个已更改的文件,但这是一件麻烦事。
是否有一个多步骤编译,并且您有一个令人困惑的中间文件make
?
我只是在多步骤编译中搞混了。
如果你有一个非标准的文件后缀,你编译成 C 代码,然后从 C 到目标代码(或任何其他类似的多步编译),那么获得可靠重新编译的关键make
是组织后缀列表,以便您的扩展从一开始就出现。不幸的是,没有一个标准的简单方法可以知道内置后缀列表是什么,所以你最终不得不做这样的事情:
SUFFIXES = .y .l .c .o # Yacc, Lex, C, Object files
EXTRA_SUFFIX = .xc # Extreme C, or Extended C, or ...
.SUFFIXES: # Eliminate all built-in suffixes
.SUFFIXES: ${EXTRA_SUFFIX} ${SUFFIXES}
第二.SUFFIXES
行将您的分机放在列表的前面。现在您可以编写规则以将.xc
文件编译为.c
or.o
文件,然后在修改.xc
文件时,即使.c
留下中间文件,该文件.xc
比.c
or.o
文件更新的事实将确保重新编译完成。
很久以前,Sun 版本make
提供了一个名为 SUFFIXES 的宏,其中包含按正确顺序排列的默认后缀。遗憾的是,这并没有被采用和标准化,因此您必须自己构建后缀列表。但宏名的选择并非完全出于偶然。