15、make中的隐式规则

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

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

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 :

$(RM) $(DIR_BUILD)

值得斟酌的问题:

对于规模较小的项目,makefile中是否也需要使用自动生成依赖关系的解决方案?

.o依赖于.h文件,h文件改动,o文件需要重新编译生成。

小项目不用,效率换维护

小结:

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

模式规则的灵活运用使得makefile具有复用性。

变量的灵活运用使得makefile具有扩展性。

规模较小的项目没必要使用自动生成依赖关系的解决方案。

规模较小的项目可以直接让源文件依赖于头文件(易于维护)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值