从头開始写项目Makefile(七):统一目标输出文件夹

【版权声明:转载请保留出处:blog.csdn.net/gentleliu。

Mail:shallnew at 163 dot com】

上一节我们把规则单独提取出来,方便了Makefile的维护,每一个模块仅仅须要给出关于自己的一些变量,然后再使用统一的规则Makefile。这一节我们继续改进我们的Makefile,到眼下为止我们的Makefile编译链接输出的目标都在源文件同文件夹下或模块Makefile同一文件夹下。当一个项目大了之后,这样会显得非常乱,寻找编译输出的文件也比較困难。

既然Makefile本身就是依照我们的的规则来编译链接程序,那么我们就能够指定其编译链接目标的文件夹。这样。我们能够清楚输出文件的地方,而且在清除已编译的目标时直接删除指定文件夹就可以。不须要一层一层的进入源码文件夹进行删除。这样又提高了效率。

既然要统一目标输出文件夹,那么该文件夹就须要存在。所以我们能够添加一条规则来创建这些文件夹。包含创建可运行文件的文件夹、链接库文件的文件夹以及.o文件的文件夹。而且文件夹还能够通过条件推断依据是否产生调试信息来区分开对应的目标文件。

一般一个project的顶层文件夹下都会有一个build文件夹来存放编译的目标文件结果,眼下我的project文件夹下通过Makefile创建的文件夹build的文件夹树例如以下:

build/            //build根文件夹
├── unix        //unix平台项目下不带调试信息输出文件夹
│   ├── bin    //存放可运行文件文件夹
│   ├── lib    //存放可文件文件夹
│   └── obj    //存放.o文件文件夹,该文件夹下将每一个模块生成的.o文件各自的文件夹以下
│       ├── ipc
│       ├── main
│       └── tools
└── unix_dbg   ////unix平台项目下带调试信息输出文件夹
    ├── bin
    ├── lib
    └── obj
        ├── ipc
        ├── main
        └── tools

14 directories, 0 files

以上文件夹中bin和lib文件夹在顶层Makefile中创建,obj及其以下模块子文件夹在各模块的Makefile里面创建。

顶层Makefile创建文件夹例如以下:

ifeq ($(DEBUG_SYMBOLS), TRUE)
>---BUILDDIR = ./build/$(PLATFORM)_dbg
else
>---BUILDDIR = ./build/$(PLATFORM)
endif

all : $(BUILDDIR) $(MODULES)

$(BUILDDIR):
>[email protected] "    Create directory [email protected] ..."
>---mkdir -p $(BUILDDIR)/bin $(BUILDDIR)/lib

我们在all目标里面添加了其依赖目标BUILDDIR。该目标相应的规则为创建bin文件夹和lib文件夹。这样每次编译之前都会创建文件夹。

各模块内部Makefile创建生成.O文件的文件夹。如上文件夹树所看到的。

类似于顶层Makefile,各模块内部Makefile须要依据平台、编译调试信息、以及模块名称来生成须要的文件夹名称,然后再添加创建该文件夹的规则。

由于每一个模块都会做这些处理。所以我们将这部分写在规则Makefile(Makefile.rule)里面。例如以下:

……
# define a root build directory base on the platform
# if without a SRC_BASE defined, just use local src directory
ifeq ($(SRC_BASE),)
>---BUILDDIR = $(MOD_SRC_DIR)
>---OBJDIR = $(MOD_SRC_DIR)
>---LIBDIR = $(MOD_SRC_DIR)
>---BINDIR = $(MOD_SRC_DIR)
else
>---ifeq ($(DEBUG_SYMBOLS), TRUE)
>--->---BUILDDIR = $(SRC_BASE)/build/$(PLATFORM)_dbg
>---else
>--->---BUILDDIR = $(SRC_BASE)/build/$(PLATFORM)
>---endif
>---OBJDIR = $(BUILDDIR)/obj/$(MODULE)
>---LIBDIR = $(BUILDDIR)/lib
>---BINDIR = $(BUILDDIR)/bin
endif
……
ifeq ($(MAKELEVEL), 0)
all : msg
else
all : lib bin
endif

lib : $(OBJDIR) $(SRC_LIB)

bin : $(OBJDIR) $(SRC_BIN)                                                                                                                       

$(OBJDIR) :
>[email protected] "   MKDIR $(notdir [email protected])..."
>[email protected] -p [email protected]
……

此时我们编译一下后查看build文件夹:

build/
└── unix_dbg
    ├── bin
    ├── lib
    └── obj
        ├── ipc
        ├── main
        └── tools

7 directories, 0 files 

因为我们是开启了调试信息,所以创建了unix_dbg文件夹,而且该文件夹下创建了bin、lib、obj文件夹及其模块文件夹,但我们没有发现有文件存放在里面。

到眼下为止,这一节只讲述怎样创建统一的目标文件存放文件夹。可是要想将编译生成的目标文件自己主动生成到这些文件夹还没有完毕。

事实上我们只须要给目标加上路径就可以,但还是有一些具体的地方须要处理,具体的我们会在下一节中讲到,这一节暂不给出最后的Makefile。

时间: 2024-11-08 01:04:31

从头開始写项目Makefile(七):统一目标输出文件夹的相关文章

从头開始写项目Makefile(三):变量的使用

[版权声明:转载请保留出处:blog.csdn.net/gentleliu. Mail:shallnew at 163 dot com] 细致研究我们的之前Makefile发现.我们还有改进的地方.就是此处: target_bin : main.o debug.o ipc.o timer.o tools.o >---gcc -o target_bin main.o debug.o ipc.o timer.o tools.o 假设添加一个源文件xx.c的话.须要在两处或多处添加xx.o文件. 我们

从头開始写项目Makefile(五):嵌套运行

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 在大一些的项目里面,全部源码不会仅仅放在同一个文件夹,一般各个功能模块的源码都是分开的,各自放在各自文件夹下.而且头文件和.c源文件也会有各自的文件夹.这样便于项目代码的维护.这样我们能够在每一个功能模块文件夹下都写一个Makefile,各自Makefile处理各自功能的编译链接工作,这样我们就不必把全部功能的编译链接都放在同一个Makefile里面,这可使得我

从零開始写游戏引擎(一) - project创建以及文件夹设置还有版本号控制

一句话提要 好的開始等于成功了一半. 创建文件夹结构 project文件夹下最好分为以下几个文件夹 Docs - 开发文档,设计文档 Assets - 角色,动作,模型和音效等 Source - 代码,project文件或者makefile也放在这里,假设有引用第三方的lib,在里面建立一个3rdParty的文件夹,放在里面. Temp - 用于防止编译生成的文件 Lib - 放置编译好的lib文件,将source编译成lib能够更好地保护源码. Game - 用于放置release buid,

从头开始写项目Makefile(七):统一目标输出目录

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 上一节我们把规则单独提取出来,方便了Makefile的维护,每个模块只需要给出关于自己的一些变量,然后再使用统一的规则Makefile.这一节我们继续改进我们的Makefile,到目前为止我们的Makefile编译链接输出的目标都在源文件同目录下或模块Makefile同一目录下,当一个项目大了之后,这样会显得很乱,寻找编译输出的文件也比较困难.既然Makefil

从头开始写项目Makefile(九):目录搜索

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 在一个较大的工程中,一般会将源代码和二进制文件(.o 文件和可执行文件)安排在不同的目录来进行区分管理.这种情况下,我们可以使用 make 提供的目录搜索依赖文件功能(在指定的若干个目录下自动搜索依赖文件).在Makefile中,使用依赖文件的目录搜索功能.当工程的目录结构发生变化后,就可以做到不更改 Makefile的规则,只更改依赖文件的搜索目录. 在我们上

从头开始写项目Makefile(六):参数传递、条件判断、include

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 在多个Makefile嵌套调用时,有时我们需要传递一些参数给下一层Makefile.比如我们在顶层Makefile里面定义的打开调试信息变量DEBUG_SYMBOLS,我们希望在进入子目录执行子Makefile时该变量仍然有效,这是需要将该变量传递给子Makefile,那怎么传递呢?这里有两种方法: 1.     在上层Makefile中使用"export&qu

从头开始写项目Makefile(四):伪目标

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 一般情况下,Makefile都会有一个clean目标,用于清除编译过程中产生的二进制文件.我们在第一节的Makefile就用到了这个 clean目标,该目标没有任何依赖文件,并且该目标对应的命令执行后不会生产clean文件. 像这种特点目标,它的规则所定义的命令不是去创建文件,而仅仅通过make指定目标来执行一些特定系统命令或其依赖为目标的规则(如all),称为

从头开始写项目Makefile(五):嵌套执行

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 在大一些的项目里面,所有源代码不会只放在同一个目录,一般各个功能模块的源代码都是分开的,各自放在各自目录下,并且头文件和.c源文件也会有各自的目录,这样便于项目代码的维护.这样我们可以在每个功能模块目录下都写一个Makefile,各自Makefile处理各自功能的编译链接工作,这样我们就不必把所有功能的编译链接都放在同一个Makefile里面,这可使得我们的Ma

从头开始写项目Makefile(三):变量的使用

[版权声明:转载请保留出处:blog.csdn.net/gentleliu.Mail:shallnew at 163 dot com] 仔细研究我们的之前Makefile发现,我们还有改进的地方,就是此处: target_bin : main.o debug.o ipc.o timer.o tools.o >---gcc -o target_bin main.o debug.o ipc.o timer.o tools.o 如果增加一个源文件xx.c的话,需要在两处或多处增加xx.o文件.我们可以