打造专业的编译环境(十四)-创新互联

        在一些大型的项目中,它的结构是很复杂的。比如下面这个

创新互联建站网站建设公司,提供成都做网站、网站制作,网页设计,建网站,PHP网站建设等专业做网站服务;可快速的进行网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,是专业的做网站团队,希望更多企业前来合作!

打造专业的编译环境(十四)

        我们来分析下这个项目的架构,项目被划分为多个不同模块。每个模块的代码用一个文件夹进行管理,文件夹由 inc,src,makefile 组成;每个模块的对外函数声明统一放置于 common/inc 中,如:common.h xxxfunc.h。

        那么我们需要打造的编译环境是:1、源码文件夹在编译时不能被改动(只读文件夹);2、在编译时自动创建文件夹(build)用于存放编译结果;3、编译过程中自动生成依赖关系,自动搜索需要的文件;4、每个模块可以拥有自己独立的编译方式;5、支持调试版本的编译选项。

        我们看看解决方案是怎样设计的

        第 1 阶段:将每个模块中的代码编译成静态库文件,如下

打造专业的编译环境(十四)

        第 2 阶段:将每个模块的静态库文件链接成最终可执行程序,如下

打造专业的编译环境(十四)

        那么第一阶段完成的任务就是完成可用于各个模块编译的 makefile 文件,每个模块的编译结果为静态库文件(.a 文件)。那么关键的实现要点就是:a> 自动生成依赖关系(gcc -MM);b> 自动搜索需要的文件(vpath);c> 将目标文件打包为静态库文件(ar crs)。我们来看看模块的 makefile 的构成,如下

打造专业的编译环境(十四)

        我们来看看这个 makefile 是怎样编写的

.PHONY : all DIR_BUILD := /mnt/hgfs/winshare/mentu/make1/14/build DIR_COMMON_INC := /mnt/hgfs/winshare/mentu/make1/14/common/inc DIR_SRC := src DIR_INC := inc TYPE_SRC := .c TYPE_INC := .h TYPE_OBJ := .o TYPE_DEP := .dep AR := ar ARFLAGS := crs CC := gcc CFLAGS := -I$(DIR_INC) -I$(DIR_COMMON_INC) ifeq ($(DEBUG),true) CFLAGS += -g endif MODULE := $(realpath .) MODULE := $(notdir $(MODULE)) DIR_OUTPUT := $(addprefix $(DIR_BUILD)/, $(MODULE)) OUTPUT := $(MODULE).a OUTPUT := $(addprefix $(DIR_BUILD)/, $(OUTPUT)) SRCS := $(wildcard $(DIR_SRC)/*$(TYPE_SRC)) OBJS := $(SRCS:$(TYPE_SRC)=$(TYPE_OBJ)) OBJS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(OBJS)) DEPS := $(SRCS:$(TYPE_SRC)=$(TYPE_DEP)) DEPS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(DEPS)) vpath %$(TYPE_INC) $(DIR_INC) vpath %$(TYPE_INC) $(DIR_COMMON_INC) vpath %$(TYPE_SRC) $(DIR_SRC) -include $(DEPS) all : $(OUTPUT)     @echo "Success! Target ==> $(OUTPUT)" $(OUTPUT) : $(OBJS)     $(AR) $(ARFLAGS) $@ $^ $(DIR_OUTPUT)/%$(TYPE_OBJ) : %$(TYPE_SRC)     $(CC) $(CFLAGS) -o $@ -c $(filter %$(TYPE_SRC), $^) $(DIR_OUTPUT)/%$(TYPE_DEP) : %$(TYPE_SRC)     @echo "Creating $@ ..."     @set -e; \     $(CC) $(CFLAGS) -MM -E $(filter %$(TYPE_SRC), $^) | sed 's,\(.*\)\.o[ :]*,$(DIR_OUTPUT)/\1$(TYPE_OBJ) $@ : ,g' > $@

       在 14 文件夹下创建 build 文件夹用于存放生成的文件,在里面继续创建 common 文件夹用于存放 common 相关的编译产生的文件,我们来看看编译结果是怎样的打造专业的编译环境(十四)

                我们看到已经产生自动依赖的 .dep 文件,和打包生成的 .a 文件了。下来我们将此 makefile 文件直接复制到 main 和 module 文件夹下,看看是否也可以生成相关文件呢(在 build 文件夹下创建 main 文件夹)

打造专业的编译环境(十四)

        我们看到已经产生自动依赖的 .dep 文件,和打包生成的 .a 文件了。下来我们看看复制到 module 文件夹是否也可以生成相关文件呢(在 build 文件夹下创建 module 文件夹)打造专业的编译环境(十四)

        现在我们的第一阶段的模块自动编译的 makefile 已经编写完成,功能也都实现了。下来我们看看第二阶段的编写,那么第二阶段的任务如下:1、完成编译整个工程的 makefile 文件;2、调用模块 makefile 编译生成静态库文件;3、链接所有模块的静态库文件,最终得到可执行程序。格式如下

打造专业的编译环境(十四)

        那么其实现的关键要点有哪些呢?1、如何自动创建 build 文件夹以及子文件夹?我们是通过 mkdir 命令来实现的;2、如何进入每一个模块文件夹进行编译?通过 cd 命令来实现;3、编译成功后如何链接所有模块静态库?通过 gcc 命令来实现。那么现在大的问题就是我们如何确定这个项目中有几个模块?在一般的项目中的各个模块在设计阶段就已经基本确定,因此,在之后的开发过程中不会频繁随意的增加或减少。

        下来我们来看看解决方案是怎样的?1、定义变量保存模块名列表(模块名变量);2、利用 Shell 中的 for 循环遍历模块名变量;3、在 for 循环中进入模块文件夹进行编译;4、循环结束后链接所有的模块静态库文件。下来我们看看在 makefile 中是如何 嵌入 Shell 的 for 循环呢,如下

打造专业的编译环境(十四)

        我们先来试试 Shell 中的 for 循环,代码如下

MODULES="common main module" for dir in $MODULES; do     echo $dir done

        编译结果如下

打造专业的编译环境(十四)

        我们看到已经正确的输出三个变量名了。下来我们来看看在 makefile 中它是如何执行的,代码如下

MODULES := common \            main \            module test :     @set -e; \     for dir in $(MODULES); \     do \         echo $$dir;\     done

        我们来看看编译结果,是否如我们所期望的那样正确输出三个变量名呢?

打造专业的编译环境(十四)

        我们看到在 makefile 中已经正确输出 Shell 中的 for 循环了。在 makefile 中嵌入 Shell 代码时,如果需要使用 Shell 变量的值,必须在变量名前加上 $$(例:$$dir)!我们来看看工程 makefile 中的构成都有哪些呢?如下

打造专业的编译环境(十四)

        下来我们来看看 compile 的代码应该怎么写

.PHONY : all compile MODULES := common \            main \            module MKDIR := mkdir RM := rm -rf DIR_PROJECT := $(realpath .) DIR_BUILD := build DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES)) all :      @echo "Success!" compile : $(DIR_BUILD) $(DIR_BUILD_SUB)     @echo "Begin to compile ..."     @set -e; \     for dir in $(MODULES); \     do \         cd $$dir && $(MAKE) all DEBUG:=$(DEBUG) && cd .. ; \     done     @echo "Compile Success!"     $(DIR_BUILD) $(DIR_BUILD_SUB) :     $(MKDIR) $@

        我们来看看编译结果打造专业的编译环境(十四)

打造专业的编译环境(十四)

        我们看到已经正确编译出 .a 文件了,如下

打造专业的编译环境(十四)

        下来我们看看怎么实现链接的,链接时应注意:a> gcc 在进行静态库链接时必须遵循严格的依赖关系,如 gcc -o app.out x.a y.a z.a。其中的依赖关系必须为:x.a->y.a,y.a->z.a,默认情况下遵循自左向右的依赖关系;b> 如果不清楚库间的依赖,可以使用 -Xlinker 自动确定依赖关系,如 gcc -o app.out -Xlinker "-(" z.a y.a x.a -Xlinker "-)"。下来我们来看看最后的 makefile 的代码是怎样编写的

.PHONY : all compile link clean rebuild MODULES := common \            main \            module MKDIR := mkdir  RM := rm -rf CC := gcc LFLAGS :=  DIR_PROJECT := $(realpath .) DIR_BUILD := build DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES)) MODULE_LIB := $(addsuffix .a, $(MODULES)) MODULE_LIB := $(addprefix $(DIR_BUILD)/, $(MODULE_LIB)) APP := app.out APP := $(addprefix $(DIR_BUILD)/, $(APP)) all : compile $(APP)     @echo "Success! Target ==> $(APP)" compile : $(DIR_BUILD) $(DIR_BUILD_SUB)     @echo "Begin to compile ..."     @set -e; \     for dir in $(MODULES); \     do \         cd $$dir && $(MAKE) all DEBUG:=$(DEBUG) && cd .. ; \     done     @echo "Compile Success!" link $(APP) : $(MODULE_LIB)     @echo "Begin to link ..."     $(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)     @echo "Link Success!" $(DIR_BUILD) $(DIR_BUILD_SUB) :     $(MKDIR) $@ clean :     $(RM) $(DIR_BUILD) rebuild : clean all

        我们来看看链接的效果

打造专业的编译环境(十四)

        我们看到已经链接成功了,并且可以正确的运行可执行程序 app.out。我们来直接 make 试试是否可以生成可执行程序。

打造专业的编译环境(十四)

        我们看到已经生成可执行程序 app.out,并且能够成功运行。我们的 makefile 算是编写完成了,那么当前整个项目的 makefile 是否存在潜在的问题?是否需要重构呢?问题一:我们在之前的模块中的 makefile 路径都是写死的,一旦项目文件夹移动,编译必将失败!如下

打造专业的编译环境(十四)

        解决方案:a> 便是在工程 makefile 中获取项目的源码路径;b> 根据项目源码路径,拼接得到编译文件夹的路径(DIR_BUILD),拼接得到全局包含路径(DIR_COMMON_INC);c> 通过命令行变量将路径传递给模块 makefile。下来我们看看改过后的代码

.PHONY : all compile link clean rebuild MODULES := common \            main \            module MKDIR := mkdir  RM := rm -rf CC := gcc LFLAGS :=  DIR_PROJECT := $(realpath .) DIR_BUILD := build DIR_COMMON_INC := common/inc DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES)) MODULE_LIB := $(addsuffix .a, $(MODULES)) MODULE_LIB := $(addprefix $(DIR_BUILD)/, $(MODULE_LIB)) APP := app.out APP := $(addprefix $(DIR_BUILD)/, $(APP)) all : compile $(APP)     @echo "Success! Target ==> $(APP)" compile : $(DIR_BUILD) $(DIR_BUILD_SUB)     @echo "Begin to compile ..."     @set -e; \     for dir in $(MODULES); \     do \         cd $$dir && \         $(MAKE) all \             DEBUG:=$(DEBUG) \             DIR_BUILD:=$(addprefix $(DIR_PROJECT)/, $(DIR_BUILD)) \             DIR_COMMON_INC:=$(addprefix $(DIR_PROJECT)/, $(DIR_COMMON_INC)) && \         cd .. ; \     done     @echo "Compile Success!" link $(APP) : $(MODULE_LIB)     @echo "Begin to link ..."     $(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)     @echo "Link Success!" $(DIR_BUILD) $(DIR_BUILD_SUB) :     $(MKDIR) $@ clean :     $(RM) $(DIR_BUILD) rebuild : clean all

        我们直接删除掉三个模块中的绝对路径,看看编译结果是否和之前一样

打造专业的编译环境(十四)

        我们看到编译是成功的。问题二:所有模块 makefile 都是相同的(复制粘贴),当模块 makefile 需要改动时,将涉及多处相同的改动!解决方案:a> 将模块 makefile 拆分为两个模板文件,mod-cfg.mk 用于定义可能改变的变量,mod-rule.mk 用于定义相对稳定的变量和规则,mod-cmd.mk 用于定义命令行相关的变量;b> 默认情况下,模块 makefile 复用模板文件实现功能(include)。关键问题是模块 makefile 如何知道模板文件的具体位置?解决方案便是通过命令行变量进行模板文件位置的传递。

mod-cfg.mk 源码

DIR_SRC := src DIR_INC := inc TYPE_SRC := .c TYPE_INC := .h TYPE_OBJ := .o TYPE_DEP := .dep

mod-rule.mk 源码

.PHONY : all MODULE := $(realpath .) MODULE := $(notdir $(MODULE)) DIR_OUTPUT := $(addprefix $(DIR_BUILD)/, $(MODULE)) OUTPUT := $(MODULE).a OUTPUT := $(addprefix $(DIR_BUILD)/, $(OUTPUT)) SRCS := $(wildcard $(DIR_SRC)/*$(TYPE_SRC)) OBJS := $(SRCS:$(TYPE_SRC)=$(TYPE_OBJ)) OBJS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(OBJS)) DEPS := $(SRCS:$(TYPE_SRC)=$(TYPE_DEP)) DEPS := $(patsubst $(DIR_SRC)/%, $(DIR_OUTPUT)/%, $(DEPS)) vpath %$(TYPE_INC) $(DIR_INC) vpath %$(TYPE_INC) $(DIR_COMMON_INC) vpath %$(TYPE_SRC) $(DIR_SRC) -include $(DEPS) all : $(OUTPUT)     @echo "Success! Target ==> $(OUTPUT)"      $(OUTPUT) : $(OBJS)     $(AR) $(ARFLAGS) $@ $^      $(DIR_OUTPUT)/%$(TYPE_OBJ) : %$(TYPE_SRC)     $(CC) $(CFLAGS) -o $@ -c $(filter %$(TYPE_SRC), $^)           $(DIR_OUTPUT)/%$(TYPE_DEP) : %$(TYPE_SRC)     @echo "Creating $@ ..."     @set -e; \     $(CC) $(CFLAGS) -MM -E $(filter %$(TYPE_SRC), $^) | sed 's,\(.*\)\.o[ :]*,$(DIR_OUTPUT)/\1$(TYPE_OBJ) $@ : ,g' > $@

cmd-cfg.mk 源码

AR := ar ARFLAGS := crs CC := gcc LFLAGS :=  CFLAGS := -I$(DIR_INC) -I$(DIR_COMMON_INC) ifeq ($(DEBUG),true) CFLAGS += -g endif MKDIR := mkdir RM := rm -fr

        模块中的 makefile 此时便变成了这样

include $(MOD_CFG) # Custmization Begin #  # DIR_SRC := src # DIR_INC := inc # # TYPE_INC := .h # TYPE_SRC := .c # TYPE_OBJ := .o # TYPE_DEP := .dep # # Custmization End include $(CMD_CFG) include $(MOD_RULE)

        我们来看看编译结果

打造专业的编译环境(十四)

        我们看到结果并没有发生改变,因此现在的改动是正确的。但是我们在模块中的 makefile 是采用注释的方式而不是直接删除的方式,这样是为什么呢?是为了可以直接在模块中的 makefile 可以改变 src 和 inc 文件夹,以便我们后面方便的进行开发。下来我们对工程 makefile 进行重构,通过拆分命令变量以及其他变量和规则到不同文件。cmd-cfg.mk 文件是定义命令相关的变量,pro-cfg.mk是定义项目变量以及编译路径变量等,pro-rule.mk是定义其他变量和规则。最后的工程 makefile 通过包含拆分后的文件构成(include)。

pro-cfg.mk 源码

MODULES := common \            module \            main             MOD_CFG := mod-cfg.mk MOD_RULE := mod-rule.mk CMD_CFG := cmd-cfg.mk DIR_BUILD := build DIR_COMMON_INC := common/inc APP := app.out

pro-rule.mk 源码

.PHONY : all compile link clean rebuild DIR_PROJECT := $(realpath .) DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES)) MODULE_LIB := $(addsuffix .a, $(MODULES)) MODULE_LIB := $(addprefix $(DIR_BUILD)/, $(MODULE_LIB)) APP := $(addprefix $(DIR_BUILD)/, $(APP)) all : compile $(APP)     @echo "Success! Target ==> $(APP)" compile : $(DIR_BUILD) $(DIR_BUILD_SUB)     @echo "Begin to compile ..."     @set -e; \     for dir in $(MODULES); \     do \         cd $$dir && \         $(MAKE) all \                 DEBUG:=$(DEBUG) \                 DIR_BUILD:=$(addprefix $(DIR_PROJECT)/, $(DIR_BUILD)) \                 DIR_COMMON_INC:=$(addprefix $(DIR_PROJECT)/, $(DIR_COMMON_INC)) \                 CMD_CFG:=$(addprefix $(DIR_PROJECT)/, $(CMD_CFG)) \                 MOD_CFG:=$(addprefix $(DIR_PROJECT)/, $(MOD_CFG)) \                 MOD_RULE:=$(addprefix $(DIR_PROJECT)/, $(MOD_RULE)) && \         cd .. ; \     done     @echo "Compile Success!"      link $(APP) : $(MODULE_LIB)     @echo "Begin to link ..."     $(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)     @echo "Link Success!"      $(DIR_BUILD) $(DIR_BUILD_SUB) :      $(MKDIR) $@      clean :      @echo "Begin to clean ..."     $(RM) $(DIR_BUILD)     @echo "Clean Success!"      rebuild : clean all

工程 makefile 源码

include pro-cfg.mk include cmd-cfg.mk include pro-rule.mk

        我们来看看编译结果

打造专业的编译环境(十四)

        我们看到编译的结果是没有发生改变的,也就是说,代码的改变是正确的。通过对专业的编译环境的打造,总结如下:1、大型项目的编译环境是由不同 makefile 构成的;2、编译环境的设计需要依据项目的整体架构设计;3、整个项目的编译过程可以分解为不同阶段;4、根据不同的阶段有针对性的对 makefile 进行设计;5、makefile 也需要考虑复用性和维护性等基本程序特性。

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

另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。

文章名称:打造专业的编译环境(十四)-创新互联
当前地址:https://www.cdcxhl.com/article42/ioeec.html

成都网站建设公司_创新互联,为您提供自适应网站网站收录网站建设微信公众号网站策划静态网站

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

成都定制网站网页设计