路径搜索的综合示例(十三)

发布时间:2020-07-01 21:58:50 作者:上帝之子521
来源:网络 阅读:443

        我们在前面学习了 makefile 中的路径搜索,那么我们今天就来实战演练下。需求分析:1、工程中不需要源码文件夹在编译时被改动(只读文件夹);2、在编译时自动创建文件夹(build)用于存放编译结果;3、编译过程中能够自动搜索需要的文件;3、编译过程中能够自动搜索需要的文件;4、makefile 易于扩展,能够复用于相同类型的项目;5、支持调试版本的编译选项。

        我们来看看这种项目的类型,如下

路径搜索的综合示例(十三)

        那么我们需要的工具原料有:a> $(wildcard $(DIR)/_pattern),用来获取 $(DIR) 文件夹中满足 _pattern 的文件;b> $(notdir _names),用于去除 _names 中每一个文件名的路径前缀;c> $(patsubst _pattern, replacement, _text),用于将 _text 中符合 _pattern 的部分替换为 replacement。这里面的关键技巧有:1、自动获取源文件列表(函数调用): SRCS := $(wildcard src/*.c);2、根据源文件列表生成目标文件列表(变量的值替换): OBJS := $(SRCS:.c=.o);3、替换每一个目标文件的路径前缀(函数调用): OBJS := $(patsubst src/%, build/%, $(OBJS))。下来我们来看看编译规则的依赖,如下图所示

路径搜索的综合示例(十三)

        下来我们来看看 makefile 怎么写,src 和 inc 文件夹还是之前的

.PHONY : all clean rebuild

DIR_BUILD := build
DIR_SRC := src
DIR_INC := inc

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

CC := gcc
CFLAGS := -I $(DIR_INC)
ifeq ($(DEBUG), true)
CFLAGS += -g
endif

MKDIR := mkdir
RM := rm -rf

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) -o $@ $^

$(DIR_BUILD)/%$(TYPE_OBJ) : %$(TYPE_SRC) $(HDRS)
    $(CC) $(CFLAGS) -o $@ -c $<

clean :
    $(RM) $(DIR_BUILD)

rebuild :
    $(MAKE) clean
    $(MAKE) all

        我们看到变量 HDRS 是先进入到 inc 文件夹下获取到所需的 .h 头文件,然后再经过 notdir 去除掉它的路径名。我们利用 TYPE_XXX 来定义相应的 头文件(或源文件或目标文件),这样做是为了让这个 makefile 具有更好的移植性。利用 vpath 来指定相应的路径。通过 DEBUG 宏判断它是否为调试版本。下来我们先来看看它是否能正常工作。

路径搜索的综合示例(十三)

        我们看到它已经正确工作了,并且在 build 文件夹下生产相应的 app.out 以及 .o 文件,原 inc 和 src 文件夹并没有被污染。这便达到了我们的要求了,如果是换一个类似的项目(包含有 .h 的头文件库和 .c 的源文件库),我们也能直接拿去这个 makefile 进行使用;如果是 C++ 项目,那么我们换个 g++ 编译器就可以正常工作。但是有个小问题,就是如果其中有一个头文件改动,整个项目就必须全部编译。我们就得思考了:对于规则较小的项目,我们在 makefile 中是否也需要使用自动生成依赖关系的解决方案呢?如果使用自动生成依赖关系的解决方案,那么整个的 makefile 代码的编写就相当复杂了。我们究竟该如何做呢?如果对于较小的项目,我们就不必使用自动生成依赖关系,因为此时不但是 makefile 的编写比较复杂,而且不利用后期的维护。

        通过对路径搜索的综合开发的学习,总结如下:1、工程项目中不希望源码文件夹在编译时被改动,模式规则的灵活运用使得 makefile 具有复用性;2、变量的灵活运用使得 makefile 具有扩展性;3、规模较小的项目没必要使用自动生成依赖关系的解决方案;4、规则较小的项目可以直接让源文件依赖于头文件(原因就是易于维护)。


        欢迎大家一起来学习 makefile 语言,可以加我QQ:243343083

推荐阅读:
  1. make 中的路径搜索(十二)
  2. 变量与函数的综合示例(九)

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

makefile 搜索路径 自动依赖

上一篇:基于AWS的云架构设计最佳实践——万字长文:云架构设计原则|附PDF下载

下一篇:Android中获取IMEI码及其它相关信息的源码

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》