c - 默认 `make` 行为从何而来?

标签 c linux makefile

我是 Makefile 的新手;因此,我遇到了一个问题,我无法想出一个好的谷歌搜索来帮助回答。

我正在运行一个虚拟操作系统,它有一个由其他人安装的软呢帽发行版。如果我在一个目录中构建自己的 Makefile,我可以设置我的 .c 文件以按照我喜欢的方式进行编译。然而,如果我简单地运行 make test,我的目录中存在 test.c,我将得到以下内容:clang -ggdb3 -std=c99 -Wall -Werror test.c -lcs50 -lm -o test

我在观察之后的问题是,这种默认的、看似普遍的 make 行为从何而来?换句话说,这个 Makefile(如果是一个)在我的文件系统中的什么位置?

最佳答案

makeseveral predefined implicit rules .其中两个是:

编译 C 程序 n.o 是从 n.c 自动生成的,配方形式为“$(CC) $(CPPFLAGS) $(CFLAGS) -c”。

链接单个对象文件 n 是通过 C 编译器运行链接器(通常称为 ld)从 n.o 自动生成的。使用的精确配方是“$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)”。

请注意,make 足够聪明,可以在有意义时有效地将上述两个规则连接成一个规则:

... 可以通过使用“.o”目标文件作为中间体来完成,但是一步完成编译和链接会更快,所以这就是完成的方式。

您可以使用 make -pn 转储预定义规则。例如:

$ make -pn -f /dev/null | grep -A3 '^%: %.c$'
make: *** No targets.  Stop.
%: %.c
#  commands to execute (built-in):
    $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@

$ 

关于c - 默认 `make` 行为从何而来?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20752332/

相关文章:

无法弄清楚为什么我的函数没有传递文件的第一个数字,而是传递最后一个数字两次

配置: error: C compiler cannot create executables (macOS: Big Sur)

java - JRE 经常崩溃。我在 Linux 中将 RXTX 与 Java (1.6) 用于串行通信。异常(exception)

linux - 当 pthread_create() 返回时,新线程是否存在?

c++ - Makefile 中无法识别 CFLAGS

c - 读取文件 C 时出错

c++ - 串行编程(硬件握手)

python - 使用python检查ubuntu中的dd状态

python - make 在 make 调用期间找不到 OpenCV 库

在 Win8/Ubuntu 上编译 Makefile 行为不同?