makefile(08)_打造专业的编译环境

20.打造专业的编译环境(上)_模块Makefile设计

20.0. 实验材料

项目架构：

其中各个文件的内容请自己填写。

20.1.大型项目的目录结构(无第三方库)

20.2.项目架构设计分析

项目被划分为不同的多个模块：
每个模块用一个文件夹进行管理，文件由inc, src, makefile构成
每个模块的对外函数统一放置于common/inc中，如common.h xxxfunc.h

20.3.项目目标

工程项目中不希望源文件夹在编译时被改动(只读文件夹)
在编译时自动创建文件夹(build)用于存放编译结果
编译过程中能够自动生成依赖关系，自动搜索到需要的文件
每个模块可以拥有自己独立的编译方式
支持调试版本和编译选项

20.4.解决方案

第一阶段：将每个模块中的代码编译称为静态库文件(compile)

第二阶段：将每个模块的静态库文件最终链接成最终的可执行程序(link)

20.5.第一阶段任务

完成可用于各个模块编译的makefile文件
完成模块的编译结果为静态库文件(.a文件)

20.5.1.关键的实现要点

自动生成依赖关系（gcc -MM）
自动搜索需要的文件（vpath）
将目标文件打包为静态库文件（ar crs）

20.5.2.模块makefile中的构成

20.6.最终结果

大幅度


.PHONY : all

DIR_BUILD := /root/w_share/DT/ToBeMaster/makefile/20/build
DIR_COMMON_INC := /root/w_share/DT/ToBeMaster/makefile/20/common/inc

DIR_SRC := src
DIR_INC := inc

TYPE_INC := .h
TYPE_SRC := .c
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) [email protected] $^

$(DIR_OUTPUT)/%$(TYPE_OBJ) : %$(TYPE_SRC)
    $(CC) $(CFLAGS) -o [email protected] -c $(filter %$(TYPE_SRC), $^)

$(DIR_OUTPUT)/%$(TYPE_DEP) : %$(TYPE_SRC)
    @echo "Creating [email protected] ..."
    @set -e;     $(CC) $(CFLAGS) -MM -E $(filter %$(TYPE_SRC), $^) | sed ‘s,\(.*\)\.o[ :]*,$(DIR_OUTPUT)/\1$(TYPE_OBJ) [email protected] : ,g‘ > [email protected]

注意：实验过程中需要自己创建build及各模块的文件夹，并将makefile中的绝对路径改为自己代码的路径。
输出结果：

这里我们看到在build/common下成功生成了依赖文件和编译后的文件，并将这些.o文件打包后放入build文件夹下。
思考：如何编写项目makefile使其能够触发模块makefile的调用，并最终生成可执行程序？

21.打造专业的编译环境_链接

21.1.第二阶段任务

完成整个工程的makefile文件；调用makefile编译生成静态库文件；链接所有模块的静态库文件，得到最终的可执行程序。

21.2.关键的实现要点

如何自动创建build文件夹及其子文件夹？
如何进入每一个模块文件夹进行编译？
编译成功后如何连接所有模块静态库？

21.3.开发中的经验假设

项目中的各个模块在设计阶段就已经基本确定，因此，在之后的开发过程中不会频繁的增加或减少

21.4.解决方案设计

1.定义变量保存模块名
2.利用shell中的for循环遍历模块名变量
3.在for循环中进入模块文件夹进行编译
4.循环结束后连接所有的模块静态库文件

21.4.1.Makefile中潜入shell的for循环

21.4.2. 注意事项

Makefile中嵌入shell代码时，如果需要使用shell变量的值，必须在变量前面加$$，譬如$$dir，用于区分该变量是shell变量而非Makefile中定义的变量。
21.4.3. shell中for循环实验

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!"

工程makefile中的关键构成

编译makefile：


.PHONY : all compile

MODULES := common            module            main

MKDIR := mkdir
RM := rm -fr

DIR_PROJECT := $(realpath .)
DIR_BUILD := build
DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MODULES))
MODULE_LIB := $(addsuffix .a, $(MODULES))

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) [email protected]

输出结果：

编译成功，在build文件夹下生成了各个模块的打包文件。

21.5. 链接时的注意事项

gcc 在进行静态库连接时，必须遵守严格的依赖关系
gcc -o app.out x.a y.a
其中的依赖关必须为：x.a -> y.a , y.a -> z.a
默认情况下遵循自左向右的依赖关系
如果不清楚库间的依赖，可以使用-Xlinker自动确定依赖关系

gcc -o app.out -Xlinker “-(”z.a y.a x.a -Xlinker”-)”
link $(APP) : $(MODULE_LIB)
    @echo "Begin to link ..."
    $(CC) -o $(APP) -Xlinker "-(" $^ -Xlinker "-)" $(LFLAGS)
    @echo "Link Success!"

21.6. 最终方案


.PHONY : all compile link clean rebuild

MODULES := common            module            main

MKDIR := mkdir
RM := rm -fr

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) [email protected]

clean :
    @echo "Begin to clean ..."
    $(RM) $(DIR_BUILD)
    @echo "Clean Success!"

rebuild : clean all

思考：
当前整个项目的makefile是否存在潜在的问题？是否需要重构？

22.打造专业的编译环境_下(编译环境重构)

当前整个项目的makefile是否存在潜在的问题？是否需要重构？

22.1.绝对路径问题

所有makefile中使用的编译路径均为写死的绝对路径，一旦项目文件移动，编译必将失败！

22.1.1.解决方案：

在工程makefile中获取项目的源码路径，根据项目源码路径：
拼接得到编译文件夹的路径（DIR_BUILD）
拼接得到全局包含路径（DIR_COMMON_INC）
通过命令行变量将路径传递给模块makefile

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!"

22.2.代码复用问题(模块makefile重构)

所有模块makefile的内容完全相同！
当模块makefile需要改动时，将涉及多处相同的改动！

22.2.1.解决方案

将模块makefile拆分为两个模板文件
mod-cfg.mk : 定义可能改变的变量
mod-rule.mk : 定义相对稳定的变量和规则
默认情况下，模块makefile复用模板文件实现功能(include)

22.2.2.解决方案

模块makefile如何指导模板文件的具体位置？
通过命令行变量进行模板文件位置的传递

$(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)) && \

最终方案：
模块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中include包含的子模块mod-cfg.mk：


DIR_SRC := src
DIR_INC := inc

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

模块makefile中include包含的子模块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) [email protected] $^

$(DIR_OUTPUT)/%$(TYPE_OBJ) : %$(TYPE_SRC)
    $(CC) $(CFLAGS) -o [email protected] -c $(filter %$(TYPE_SRC), $^)

$(DIR_OUTPUT)/%$(TYPE_DEP) : %$(TYPE_SRC)
    @echo "Creating [email protected] ..."
    @set -e;     $(CC) $(CFLAGS) -MM -E $(filter %$(TYPE_SRC), $^) | sed ‘s,\(.*\)\.o[ :]*,$(DIR_OUTPUT)/\1$(TYPE_OBJ) [email protected] : ,g‘ > [email protected]

模块makefile中include包含的子模块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

22.3.工程makefile的重构

拆分命令变量，项目变量，以及其他变量和规则到不同文件
cmd-cfg.mk : 定义命令相关的变量
pro-cfg.mk : 定义项目变量以及编译路径变量等
pro-rule.mk : 定义其他变量和规则
最后的makefile通过包含拆分后的文件构成(include)
最终方案：
项目主makefile:

include pro-cfg.mk
include cmd-cfg.mk
include 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

项目makefile中include包含的子模块pro-rele.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) [email protected]

clean :
    @echo "Begin to clean ..."
    $(RM) $(DIR_BUILD)
    @echo "Clean Success!"

rebuild : clean all

22.4.总结

大型项目的编译环境是由不同的makefile构成的
编译环境的设计需要根据项目的整体架构设计
整个项目的编译过程可以分解为不同阶段
根据不同的阶段由针对性的对makefile进行设计
Makefile也要考虑复用性和维护性等基本的程序特性

原文地址：http://blog.51cto.com/11134889/2109124

时间： 2024-10-26 06:12:46

makefile(08)_打造专业的编译环境的相关文章

打造专业的编译环境（十四）

在一些大型的项目中,它的结构是很复杂的.比如下面这个 我们来分析下这个项目的架构,项目被划分为多个不同模块.每个模块的代码用一个文件夹进行管理,文件夹由 inc,src,makefile 组成:每个模块的对外函数声明统一放置于 common/inc 中,如:common.h xxxfunc.h. 那么我们需要打造的编译环境是:1.源码文件夹在编译时不能被改动(只读文件夹):2.在编译时自动创建文件夹(build)用于存放编译结果:3.编译过程中自动生成依赖关系,自动搜索需要的文件:4.每个模块可

第二十二课 打造专业的编译环境（下）

顶层目录如下: 顶层makefile: 1 include pro-cfg.mk 2 include cmd-cfg.mk 3 include pro-rule.mk cmd-cfg.mk: 1 AR := ar 2 ARFLAGS := crs 3 4 CC := gcc 5 LFLAGS := 6 CFLAGS := -I$(DIR_INC) -I$(DIR_COMMON_INC) 7 8 ifeq ($(DEBUG),true) 9 CFLAGS += -g 10 endif 11 12

第二十一课 打造专业的编译环境（中）

1 .PHONY : all compile link clean rebuild 2 3 MODULES := common 4 module 5 main 6 7 MKDIR := mkdir 8 RM := rm -fr 9 10 CC := gcc 11 LFLAGS := 12 13 DIR_PROJECT := $(realpath .) 14 DIR_BUILD := build 15 DIR_BUILD_SUB := $(addprefix $(DIR_BUILD)/, $(MO

make--打造专业的编译环境

一.项目的目录结构 分析A.项目被划分为多个不同模块1.每个模块的代码用一个文件夹进行管理--文件夹由inc,src,makefille构成2.每个模块的对外函数声明统一放置于common/inc中--如:commom.h xxxfunc.hB.需要打造的编译环境1.编码文件夹在编译时不能被改动2.在编译时自动创建文件夹用于存放编译结果3.编译过程中能够自动生成依赖关系,自动搜索需要的文件4.每个模块可以拥有自己独立的编译方式5.支持调试版本的编译选项C.解决方案的设计第1阶段:将每个模块中的代

搭建Ubuntu下c/c++编译环境【转】

1.       安装Ubuntu. 2.       安装gcc 方法一: sudo apt-get  install  build-essential 安装完了可以执行 gcc--version的命令来查看版本,输出如下: gcc(GCC)4.2.3(Ubuntu4.2.3-2ubuntu7) Copyright(C)2007FreeSoftwareFoundation,Inc. 编译则使用Ubuntu gcc命令.要往下学习首先就得熟悉gcc命令的用法. Ubuntu gcc命令提供了非常

makefile(01)_初识

0. 声明 本系列(makefile)文章,从零基础开始,通过实验逐步分析makefile的语法特性,并最终打造一个可复用.可移植的专业编译环境.参考:1.DT 唐老师门徒计划课程2.GNU make 手册:http://www.gnu.org/software/make/manual/make.html 1.Make与makefile Make是一个应用程序:接续源程序之间的依赖关系,根据依赖关系自动维护编译工作,执行宿主操作系统中的各种命令. Makefile是一个描述文件:定义了系列的规则

Linux下编译环境配置和搭建

配置安装虚拟机和Ubuntu系统: 虚拟机安装: VMware Workstation版本:vmware-workstation-full-9.0.2-1031769 安装前请大家切记BIOS的VT功能,不开的话安装Ubuntu 64bit 是不允许的.(设置安装64bit系统注意事项) 开启方式:Bios -> Security -> System Security -> enable VT 开启后就可以安装VM并自行破解. 注意:要先开启VT开安装VM,先安装VM再开启VT的话是不行

爱加密出席2014可信云服务大会，协力打造移动App安全环境

2014年7月15日和7月16日,在工业和信息化部指导下,2014可信云服务大会在北京国际会议中心第一会议厅隆重召开.中国通信标准化协会秘书长杨泽民.中央国家机关政府采购中心主任王力达.工信部电信研究院院长曹淑敏.工信部总工程师张峰.工信部通信发展司副司长陈家春.财政部政府采购管理办公室主任王瑛等出席会议. 目前,云计算在国内已经进入快速发展阶段,用户对于云服务的接受程度也大幅提高,产业具有良好的发展前景.在该产业蓬勃发展的同时,云计算市场也存在鱼龙混杂,服务质量参次不齐,导致用户不信任,给云计

Android4.4编译环境折腾记

题记:感觉是时候写点什么了=_=! 第一次安装了ubuntu14.04.5,官网下载的iso,官网下的jar,编译android4.x需要安装jdk6,更高的版本会有问题,baidu到很多搭建环境的步骤,这个不多说,在win7下使用EasyBCD引导安装的ubuntu,1TB硬盘果断装了双系统,事实证明没删掉win7是个多么明智的决定,在jdk方面,android4.4比4.0要多配置一个javap,其他都一样 1 update-alternatives --install "/usr/bin/