15、make中的隐式规则

最新推荐文章于 2023-05-25 21:10:35 发布

WSchen12

最新推荐文章于 2023-05-25 21:10:35 发布

阅读量666

点赞数

如果同一个目标的命令拆分的写到不同地方，会发生什么？

下面的程序怎么执行？为什么？

makefile中出现同名目标时：

依赖：所有的依赖将合并在一起，成为目标的最终依赖。

命令：当多处出现同一目标时，make发出警告。所有之前定义的命令被最后定义的命令取代。

注意事项：

当使用include关键字包含其他文件时，需要确保被包含文件中的同名目标只有依赖，没有命令。否则，同名目标的命令将被覆盖。

什么是隐式规则（built-in rules）？

make提供了一些常用的，例行的规则实现。

当相应目标的规则未提供时，make尝试使用隐式规则。

下面的makefile能成功编译吗？

@echo "$(.VARIABLES)"

所有预定义变量的名字。

cc：第一个c是C语言，第二个是compler第一个字母。cc是unix下标准编译器，查看cc

ls -l /user/bin/cc

ls -l /etc/alternatives/cc

/etc/alternatives/cc -> /usr/bin/gcc /所以cc就是gcc了

初探隐式规则：

make提供了生成目标文件的隐式规则。

隐式规则会使用预定义变量完成编译工作。

改变预定义变量将部分改变隐式规则的行为。

当存在自定义规则时，不在使用隐式规则。

小结：

当多处出现同一命令时，只有最后定义的命令有效、

make提供了一系列的隐式规则可使用。

当makefile中未定义规则时，尝试使用隐式规则。

隐式规则中可能使用make中的预定义变量。

改变预定义变量可部分改变预定义规则的行为。

16、隐式规则下

当make发现目标的依赖不存在时：

尝试通过依赖名逐一查找隐式规则。

并且通过依赖名推导可能需要的源文件。

app.out : main.o func.o 1、发现目标依赖不存在。2、查找隐式规则，并自动推导出：func.o func.c 3、根据文件后缀自动推导编译命令： cc -c -o func.o func.c

$(CC) -o $@ $^

隐式规则的副作用

编译行为难以控制：大量使用隐式规则则可能产生意想不到的编译行为。

编译效率低下：make从隐式规则和自定义规则中选择最终使用的规则。

隐式规则链：

当依赖的目标不存在时，make会极力组合各种隐式规则对目标进行创建，进而产生意料之外的编译行为。

例：

需要名为N.o的目标：N.y->N.c->N.o 非常复杂了

make提供了多少隐式规则，如何查看隐式规则？

1000个左右

查看隐式规则：

查看所有：make -p

查看具体规则：make -p | grep "%.o" 重定向到grep命令

隐式规则的禁用：

局部禁用：

在makefile中自定义规则。

在makefile中定义模式（如：%.o : %.p）

全局禁用：

make -r

后缀规则简介：

后缀规则是旧式的“模式规则”。通过什么文件产生什么目标

可以通过后缀描述的方式自定义规则。

.cpp.o :（通过cpp文件得到.o文件）

@echo "suffix rule"

g++ -o $@ -c $^

通过.cpp文件产生.o文件-->例：func.cpp->fun.o

双后缀规则：

定义一对文件后缀（依赖文件后缀和目标文件后缀）

如： .cpp.o<-->%.o : %.cpp

单后缀规则：

定义单个文件后缀（源文件后缀）

如： .c<-->% : %.c 产生任意后缀

关于后缀规则的注意事项：

后缀规则中不允许有依赖。

后缀规则必须有命令，否则无意义。

后缀规则将逐步被模式规则取代。

小结：

隐式规则可能造成意想不到的行为。

在实际工程项目中尽量不使用隐式规则。

后缀规则时一种旧式的模式规则。

后缀规则将被模式规则取代。

17、make中的路径搜索

问题：

在实际工程项目中，所有的源文件和头文件都放在一个同一个文件夹中吗？

常用的源码管理方式：

项目中的makefile必须能够正确的定位源文件和依赖的文件，最终编译产生可执行程序。

下面的makefile能够成功编译吗？

特殊的预定义变量VPATH(全大写)

VPATH变量的值用于指示make如何查找文件。

不同文件夹可作为VPATH的值同时出现。

文件夹的名字之间需要使用分隔符进行区分。

例1：VPATH : =Inc src (空格)

例2：VPATH : =inc;src (分号)

例3：VPATH : =inc:src (冒号)

make对于VPATH值的处理方式：

当前文件夹找不到需要的文件时，VPATH会被使用。

make会在VPATH指定的文件夹中依次搜索文件。

当多个文件夹存在同名文件时，选择第一次搜索到的文件。

注意事项：

VPATH只能决定make的搜索路径，无法决定命令的搜索路径。

对于特定的编译命令（gcc），需要独立指定编译搜索路径。

gcc -I(编译选项，指定gcc的头文件搜索路径) include-path（路径参数，具体需要gcc搜索的路径）

OBJS :=func.o main.o
INC :=inc
SRC :=src
VPATH :=$(INC) $(SRC)
CFLAGS :=-I $(INC)
hello.out :$(OBJS)
@gcc -o $@ $^
@echo "target file ==>$@"
$(OBJS) :%.o :%.c func.h

@gcc $(CFLAGS) -o $@ -c $<

VPATH存在的问题：

当inc文件夹中意外出现源文件（C/Cpp文件），那么可能产生编译错误。

替换方案：vpath关键字（全小写）

为不同类型的文件指定不同的搜索路径。

语法：

在Directory中搜索符合Pattern的规则的文件。

vpath Pattern Directory

例：vpath %.h inc

vpath %.c src

也可以取消搜索规则：

取消已经设置的某个搜索规则

vpath Pattern

例：vpath %.h inc #在inc中搜索.h文件

vpath %.h #不再到inc中搜索.h文件

取消所有已经设置的规则：vpath

OBJS :=func.o main.o
INC :=inc
SRC :=src
vpath %.h $(INC)
vpath %.c $(SRC)
CFLAGS :=-I $(INC)
hello.out :$(OBJS)
@gcc -o $@ $^
@echo "target file ==>$@"
#vpath %.h
$(OBJS) :%.o :%.c func.h

@gcc $(CFLAGS) -o $@ -c $<

小结：

VPATH变量用于指示make如何查找文件。

make会在VPATH指定的文件夹中依次搜索文件。

vpath关键字可以为不同类型的文件指定不同的搜索路径。

vpath比VPATH更灵活易用，可动态设置/取消搜索路径。

18、路径搜索下

问题一：

当VPATH和vpath同时出现时，make会如何处理？

下面的项目中会选择哪一个文件编译？

VPATH :=src1
CFLAGS :=-I inc
vpath %.c src2
vpath %.h inc
app.out :func.o main.o
@gcc -o $@ $^
@echo "target file ==>$@"
%.o :%.c func.h
@gcc $(CFLAGS) -o $@ -c $<

试验结论：

make首先在当前文件夹搜索需要的文件。

搜索失败：

make优先在vpath关键字指定的文件夹中搜索目标文件。

当vpath搜索失败时，转而搜索VPATH指定的文件夹。

VPATH ：=src1 src3

vpath %.c src2

==>src2 -> src1 ->src3

问题二：

当使用vpath对同一个Pattern指定多个文件夹时，make会如何处理。

下面的项目会选择哪一个文件进行编译？

CFLAGS :=-I inc
vpath %.c src2
vpath %.c src1
vpath %.h inc
app.out :func.o main.o
@gcc -o $@ $^
@echo "target file ==>$@"
%.o :%.c func.h
@gcc $(CFLAGS) -o $@ -c $<

实验结论：

make首先在当前文件夹搜索需要的文件。

如果失败：

make以自上而下的顺序搜索vpath指定的文件夹、

当找到目标文件，搜索结束。

vpath %.c src3

vpath %.c src1

vpath %.c src2

==>src3->src1->src2

vpath不使用隐式规则，VPATH会使用隐式规则

VPATH :=src1

vpath %.c src2

当把.c文件改为.cpp文件时，vpath不会调用隐式规则从.app到.o，而VPATH会调用隐式规则从.app到.o的转换。

最好用vpath。

问题三：

通过VPATH指定搜索路径后，make如何决定目标文件的最终位置？

app.out会生成在那个文件夹中？

把app.out移动到src中，

改动源文件后重新make

还是会在当前文件夹中创建新的app.out。

试验结论：

当app.out完全不存在：make在当前文件下创建app.out

当src文件夹中存在app.out:所有目标和依赖的新旧关系不变，make不会重新创建app.out（最新的）。当依赖文件被更新，make在当前文件夹下创建app.out。

问题：当依赖改变时，如何使得src下的app.out被更新？

解决方案：

使用GPATH特殊变量指定目标文件夹。

GPATH := src

当app.out完全不存在：make默认在当前文件夹创建app.out。

当app.out存在于src（把app.out拖动到src），且依赖文件被更新：make在src中创建app.out。

但凡使用了VPATH，考虑一下是否要用GPAHT.

GPATH :=src
VPATH :=src
CFLAGS :=-I inc
app.out :func.o main.o
@gcc -o $@ $^
@echo "target file ==>$@"
%.o :%.c inc/func.h

@gcc $(CFLAGS) -o $@ -c $<

工程项目中的几点建议：

尽量使用vpath为不同文件指定搜索路径。

不要在源码文件夹中生成目标文件。

为编译得到的结果创建独立的文件夹。

避免VPATH和GPAHT特殊变量的使用。

19、路径搜索综合示例

需求分析：

工程项目中不希望源码文件夹在编译时被改动（只读文件夹）

在编译时自动创建文件夹（build）用于存放编译结果。

编译过程中能够自动搜索需要的文件。

makefile易于扩展，能够复用于相同类型的项目。

支持调试版本的编译选项。

工具原料：

$(wildcard $(DIR)/_pattern)

获取$(DIR)文件夹中满足_pattern的文件。

$(notdir _names)

去除_names中每一个文件名的路径前缀。

$(patsubst _pattern, replacement, _text)

将 _text中符合_pattern的部分替换为replacement。

关键技巧：

1、自动获取源文件列表（函数调用）

SRCS :=$(wildcard src/*.c)

2、根据源文件列表生成目标文件列表（变量的值替换）

OBJS :=$(SRCS: .c=.o)

3、替换每一个目标文件的路径前缀（函数调用）src前缀换为build前缀

OBJS :=$(patsubst src/%,build/%, $(OBJS))

编译规则的依赖：图

all->依赖于（build，app.out） app.out->(build，%.o) %.o->build(生成到)

自动生成文件夹build。

可复用性和可扩展性需要通过变量得到

cd make 到make中

cd .. 返回上一级目标

.PHONY : all clean
DIR_BUILD :=build
DIR_SRC :=src
DIR_INC :=inc
CC :=gcc
CFLAGS := -I $(DIR_INC)
MKDIR :=mkdir
RM :=rm -fr
APP := $(DIR_BUILD)/app.out
HDRS :=$(wildcard $(DIR_INC)/*.h)
HDRS :=$(notdir $(HDRS))
OBJS :=$(wildcard $(DIR_SRC)/*.c)
OBJS :=$(OBJS:.c=.o)
OBJS :=$(patsubst $(DIR_SRC)/%, $(DIR_BUILD)/%, $(OBJS))
vpath %.h $(DIR_INC)
vpath %.c $(DIR_SRC)
all:$(DIR_BUILD) $(APP)
@echo "target file==>$(APP)"
$(DIR_BUILD):
$(MKDIR) $@
$(APP) : $(OBJS)
$(CC) -o $@ $^
#touwenjian zuowei yilai wenjian
$(DIR_BUILD)/%.o : %.c $(HDRS)
$(CC) $(CFLAGS) -o $@ -c $<
clean :
$(RM) $(DIR_BUILD)

扩展性差一点，.cpp就不可以了。

在次使用变量、

LFLAGS 链接选项

-g 调试版本的程序

makefile可以复用到别的项目中，改变名字 .c改为 .cpp gcc改为g++

用到了多线程，链接需要指定链接选项，指定需要使用多线程库。

改动 LFLAGS :=-pthread 链接到多线程库

.PHONY : all clean
DIR_BUILD :=build
DIR_SRC :=src
DIR_INC :=inc

TYPE_INC := .h
TYPE_SRC := .c
TYPE_OBJ := .o

CC :=gcc
LFLAGS :=

CFLAGS := -I $(DIR_INC)
ifeq ($(DEBUG),true)
CFLAGS += -g
endif
MKDIR :=mkdir
RM :=rm -fr
APP := $(DIR_BUILD)/app.out
HDRS :=$(wildcard $(DIR_INC)/*$(TYPE_INC))
HDRS :=$(notdir $(HDRS))
OBJS :=$(wildcard $(DIR_SRC)/*$(TYPE_SRC))
OBJS :=$(OBJS:$(TYPE_SRC)=$(TYPE_OBJ))
OBJS :=$(patsubst $(DIR_SRC)/%, $(DIR_BUILD)/%, $(OBJS))
vpath %$(TYPE_INC) $(DIR_INC)
vpath %$(TYPE_SRC) $(DIR_SRC)
all:$(DIR_BUILD) $(APP)
@echo "target file==>$(APP)"
$(DIR_BUILD):
$(MKDIR) $@
$(APP) : $(OBJS)
$(CC) $(LFLAGS) -o $@ $^
#touwenjian zuowei yilai wenjian
$(DIR_BUILD)/%$(TYPE_OBJ) : %$(TYPE_SRC) $(HDRS)
$(CC) $(CFLAGS) -o $@ -c $<
clean :