『Linux项目自动化构建工具』make/Makefile

简介: 『Linux项目自动化构建工具』make/Makefile

前言

如题可知,make/Makefile为在Linux下的项目自动化构建工具;

在上一篇文章『Linux - gcc / g++』c程序翻译过程 中讲解了C/C++程序的翻译过程;

而make/Makefile即可以看成,是Makefile在使用gcc/g++使在Linux环境下能够更好的高效率的进行项目构建;

在此之前首先要对make/Makefile进行说明:

  • make
    首先,make是一条命令,也可以说通过make命令可以解析Makefile文件;
  • Makefile
    而Makefile是一个文件,是用来告诉make命令该如何编译工程,生成可执行程序;

当然,必须要现有Makefile文件才能使用make命令解析Makefile文件从而达到自动化构建项目的作用;


编写Makefile

假设存在一个.cpp文件,代码为:

#include<iostream>
//测试代码 用来测试make
int main()
{
  std::cout<<"it's a test file!"<<std::endl;
}

若是需要使该文件生成对应可执行文件即可使用命令:

g++ -o mytest test.cpp   #将程序进行翻译直到链接结束生成可执行程序为止

而现在需要一个对应的Makefile文件来使其可以自动化构建项目;

先用命令touch来建立一个Makefile文件;

touch Makefile

建立完Makefile文件后使用vim进行编辑;

mytest:test.cpp 
  g++ -o mytest test.cpp 
.PHONY:clean  
clean:      
  rm -rf mytest

拥有该Makefile文件后即可使用make命令对Makefile文件进行解析从而达到构建项目的的效果;

当然对应的也可以进行项目的清理;

由于Makefile文件中拥有一个用来清理项目的伪目标clean,在调用时使用命令:

make clean

即可对项目进行清理,当然会根据我们在Makefile文件中所指定的规则进行清理;

既然如此那么在Makefile文件中的每一行分别是什么?

由上到下每一行依次分别为:

  • 第1行 - 依赖关系
mytest:test.cpp

#以冒号:作为分界,冒号的左侧为目标文件,冒号的右侧为依赖文件列表;

目标文件即为目标生成的文件,依赖文件列表即为所生成的文件依赖的文件,在这里可以表示为,这里的可执行文件mytest是由test.cpp翻译生成的,所以依赖于test.cpp文件;

同时在Makefiel的语法中,目标文件必须在顶格,且必须跟冒号:


  • 第2行 - 依赖方法
g++ -o mytest test.cpp #依赖方法 该行必须紧挨着第一行,不能空行,且该行必须以table键开头

#可以理解为,生成mytest可执行程序时需要依靠命令g++ -o mytest test.cpp

同时在语法中,依赖方法所在行前必须有其他依赖方法或者是紧跟依赖关系行;


  • 第4行 - .PHONY伪目标修饰
.PHONY:clean

该关键字.PHONY的作用即为修饰 : 后的目标文件为伪目标;


  • 第5,6行
    与第1,2行相同,不同的是在这里的依赖关系中,目标文件clean不需要依赖文件;
    此处是用作清除,而在大多数的开源中所使用的清除都是用的clean;
    也可以使用其他名;
clean:      #该行与第一行相同,冒号左边为目标文件,右侧为依赖文件列表,不同的是该目标文件不需要依赖文件
  rm -rf mytest  #依赖方法
  #该处的四五六行是用来清理的
  #有了四五六行即可以在Makefile文件所对应的文件夹中使用 make clean 进行对应文件的清理;

在执行make命令时 , 默认使用Makefile文件中的第一对依赖关系与依赖方法;(自顶向下扫描会形成第一个遇到的目标文件)

此处若是将 形成对应文件的依赖关系依赖方法清理对应文件的依赖关系依赖方法 调换再执行make命令时;

首先将会执行 清理对应文件的依赖关系与方法 ;


.PHONY:所修饰的伪目标

在很多教材之中,对于伪目标的描述是这样的:“伪目标是总是被执行的”

但是这里的总是被执行是什么意思?

若是多次进行make,则只有第一次会被执行;

而后面的几次将不会被执行;

而若是执行make clean时则不同;

每一次的make clean都会被执行;

这个原因就是因为clean被修饰成为了伪目标;

这里的 “ 伪目标总是被执行的 ” 这句话的意思即为,伪目标总是会根据依赖关系,执行此依赖方法;

在一般的习惯中,都会将clean设置为伪目标;

若是希望其他的目标文件同样可以总是被执行,可以将其修饰为伪目标;


编译器和Makefile是如何得知可执行程序是最新的

在我们make了一次之后,在没有修改源文件之前再次make时都会显示一个类似于 “当前的可执行程序为最新” 的提示;

但若是在该处修改了源文件,并再次进行make指令时又会重新生成相应的可执行程序;

既然如此,那么编译器或者Makefile是如何知道当前可执行程序是最新的呢?

在Linux中有一条为 stat 的命令,该命令可以查看一个文件中最重要的三个时间;

stat mytest

这三个时间分别为:

时间 内容
(Access)访问时间 访问文件的修改已经在Linux内核中进行了改动,在原先的Linux版本中,对于文件的访问(cat,ls等操作)都是会进行修改的,而这种,由于对文件的访问是一个高频操作;而文件是存在磁盘当中,若是每次访问文件都对Access进行改动的话,说明这个高频操作将会大量的去对磁盘进行访问,而高频的磁盘访问定会降低访问程序的效率;故在Linux的内核中修改为,当对文件进行一段时间的访问(累计)过后才会修改该属性;
(Modify)修改(内容)时间 文件内容的修改时间;
(Change)修改(属性)时间 文件属性的修改时间

回归正题,为什么编译器和Makefile能够知道当前的可执行程序是最新的;

真正来说,在使用make指令来对Makefile进行操作时,若是当前已经拥有一个可执行程序;

则会将各个源文件与当前的可执行程序进行Modify时间的比较,若是当前可执行文件的修改时间晚于各个源文件,则代表当前可执行程序为最新;


多文件使用Makefile

假设当前有三个文件(不包括Makefile文件),分别为两个源文件(test.cpp main.cpp)与一个头文件(test.hpp);

若是用指令编译则为:

g++ main.cpp test.cpp -o test

在Makefile文件中也可以使用该指令;

mytest:test.cpp main.cpp
  g++ main.cpp test.cpp -o mytest
.PHONY:clean #修饰为伪目标
clean:
  rm -f mytest

但是一般多文件进行Makefile操作时习惯使用.o进行连接;

mytest:test.o main.o #所生成的文件依赖test.o与main.o文件
  g++  test.o main.o -o mytest #需要生成mytest文件需要对两个.o文件进行链接(头文件被#include展开后可以不用再管)
main.o:main.cpp #make首先会看到上面第一对依赖关系与依赖方法,但是上面的依赖文件列表并没有.o文件 将会继续往下找第二对依赖关系与方法
  g++ -c main.cpp -o main.o 
test.o:test.cpp #以此类推
  g++ -c test.cpp -o test.o
.PHONY:clean
clean:
  rm -f *.o mytest    #此处删除所有的.o文件同时删除mytest文件

相关文章
|
1月前
|
安全 Linux 测试技术
Kali Linux预装的自动化渗透测试工具
Kali Linux预装的自动化渗透测试工具
43 2
|
2月前
|
Linux Python
【Azure 应用服务】Azure App Service For Linux 上实现 Python Flask Web Socket 项目 Http/Https
【Azure 应用服务】Azure App Service For Linux 上实现 Python Flask Web Socket 项目 Http/Https
|
2月前
|
存储 关系型数据库 Linux
【Azure 应用服务】App Service For Linux 部署PHP Laravel 项目,如何修改首页路径为 wwwroot\public\index.php
【Azure 应用服务】App Service For Linux 部署PHP Laravel 项目,如何修改首页路径为 wwwroot\public\index.php
|
2月前
|
Linux C# C++
【Azure App Service For Container】创建ASP.NET Core Blazor项目并打包为Linux镜像发布到Azure应用服务
【Azure App Service For Container】创建ASP.NET Core Blazor项目并打包为Linux镜像发布到Azure应用服务
|
2月前
|
NoSQL Linux Shell
在Linux中,GNU项目的重要性是什么?
在Linux中,GNU项目的重要性是什么?
|
29天前
|
运维 Ubuntu Devops
自动化运维工具的魅力:Ansible入门
【9月更文挑战第5天】在快速变化的IT世界里,自动化运维不再是可选项,而是必需品。Ansible,一款简单却强大的自动化工具,正成为众多DevOps工程师的首选。本文将带你了解Ansible的基本概念、安装步骤以及如何编写简单的Playbook,从而开启你的自动化之旅。
67 36
|
6天前
|
机器学习/深度学习 运维 Cloud Native
构建高效运维体系:从自动化到智能化的演进之路
在当今数字化时代,运维作为信息技术的重要支柱,其效率与创新能力直接关系到企业信息系统的稳定性和业务连续性。本文将探讨如何通过技术手段,实现运维从传统手工操作向自动化、智能化的转变,进而构建一个高效、可靠的运维体系。我们将从自动化工具的应用开始,逐步深入到智能运维的实践,最终展望云原生架构下的运维未来趋势。
|
10天前
|
机器学习/深度学习 人工智能 运维
构建高效运维体系:从自动化到智能化的演进之路
在当今数字化时代,运维作为保障企业IT系统稳定运行的关键环节,正经历着前所未有的变革。本文将探讨如何通过实施自动化和引入智能化技术,构建一个更加高效、可靠的运维体系,以应对日益复杂的业务需求和技术挑战。
22 1
|
27天前
|
存储 弹性计算 运维
自动化监控和响应ECS系统事件
阿里云提供的ECS系统事件用于记录云资源信息,如实例启停、到期通知等。为实现自动化运维,如故障处理与动态调度,可使用云助手插件`ecs-tool-event`。该插件定时获取并转化ECS事件为日志存储,便于监控与响应,无需额外开发,适用于大规模集群管理。详情及示例可见链接文档。
|
20天前
|
机器学习/深度学习 运维 安全
构建高效运维体系:从自动化到智能化的演进之路
在数字化转型的浪潮中,运维管理作为信息技术基础设施的重要支柱,正经历着从传统手工操作向自动化、智能化的深刻变革。本文将探讨如何通过引入自动化工具和平台,实现运维流程的标准化与效率提升;进而利用大数据分析和人工智能技术,迈向预测性维护和智能决策支持的高级阶段。通过案例分析,揭示成功转型的关键因素,为运维专业人士提供一套可借鉴的升级路径。
下一篇
无影云桌面