Linux:自动化构建 - make

简介: Linux:自动化构建 - make

make基本概念

make是一个用于自动化编译和构建过程的工具。它主要用于管理大型软件项目的构建过程,帮助开发者更高效地编译和部署代码,并减少人为错误的发生,这使得软件的编译和部署变得更加自动化和可靠。

其中make是一个命令,执行该命令需要当前操作目录下有一个名为makefile或者Makefile的文件,在makefile内部编写指令,随后就可以通过make快速执行一系列的指令了。

当前目录下有一个test.c文件,需要把该文件编译为可执行文件mybin。该过程就可以用make来

自动执行。我先编写一个makefile,然后再讲解,代码如下:

mybin:test.c
    gcc -o mybin test.c
clean:
    rm -f mybin   

其中我们可以看到两条熟悉的指令:gcc -o mybin test.c,该指令完成把test.c文件编译为可执行文件mybinrm -f mybin,该指令完成对mybin的删除。

有了这个文件后,我们就可以直接输入make,完成对test.c的编译:

一开始目录下只有makefiletest.c两个文件,执行指令make后,Linux自动执行了指令gcc -o mybin test.c,最后目录中就出现了编译好的可执行文件mybin

我们也可以输入make clean,完成对mybin的删除:

执行make clean后,Linux自动执行了指令rm -f mybin,完成了mybin的删除。

看到其大致是如何执行后,我现在讲解以上代码中各个部分的作用是啥。

mybin:test.c
    gcc -o mybin test.c
  • mybin:test.c:这个由两个文件名通过一个:隔开的整体,叫做依赖关系。左侧的mybin叫做目标文件,右侧的test.c叫做依赖文件列表
  • gcc -o mybin test.c:这个语句叫做依赖方法

那么依赖关系目标文件依赖文件列表依赖方法之间有什么关系呢?

  1. 目标文件:
  • 目标文件是 make 命令要生成的文件,通常是可执行程序、库文件或中间目标文件。
  • 每个目标文件都有一条或多条命令来生成它。
  • 目标文件可以有多个依赖文件,这些依赖文件共同决定了目标文件的生成过程。
  1. 依赖文件列表:
  • 依赖文件列表描述了目标文件所依赖的输入文件,如源代码文件、头文件、库文件等。
  • 依赖文件列表告诉 make 哪些文件的变化会导致目标文件需要重新生成。
  • 依赖文件列表可以包含多个文件,用空格分隔。
  1. 依赖关系:
  • 目标文件与其依赖文件之间形成依赖关系。
  • 如果依赖文件中任何一个文件发生变化,目标文件就需要重新生成。
  • 依赖关系可以形成层次结构,实现文件之间的层次依赖。
  1. 依赖方法:
  • 依赖方法是生成目标文件所需执行的命令。
  • 依赖方法通常是 shell 命令,用于编译、链接等操作。
  • 依赖方法可以包含多条命令,每条命令用回车分隔。

这里要注意,依赖方法前面必须用一个Tab键隔开,不可以是四个空格。

再看到后半段:

clean:
    rm -f mybin

该代码中,目标文件是clean,没有依赖文件列表,依赖关系是删除mybin的指令。只要执行make clean就会执行后面的代码rm -f mybin ,从而实现文件的删除。


左侧的目标文件clean叫做伪目标,伪目标是 make 中的一种特殊目标,它不对应任何文件,只是用来执行一些命令。常见的伪目标有 all、clean、install 等。

那么现在有一个问题,为什么执行mybin:test.c直接使用make就可以,但是make clean才能执行clean呢?

make后面不接任何内容时,则在makefile中从上往下查找,找到第一个依赖关系执行

现有如下makefile

mybin:test.o
    gcc -o mybin test.o
test.o:test.s
    gcc -c -o test.o test.s
test.s:test.i
    gcc -S -o test.s test.i
test.i:test.c
    gcc -E -o test.i test.c

clean:
    rm -f test.i test.s test.o mybin

该文件完成了一个连续的C语言程序编译链接过程,但是其有一个问题在于,C语言编译过程应该依次生成.i,.s,.o文件,最后生成mybin。第一条依赖关系执行的时候,就缺少test.o文件,第二条依赖关系缺少test.s文件,以此类推,整个编译过程都是反的。那么该makefile可以执行成功吗?

我们试试:

可以看到,其执行成功了,这是为什么?我只输入了make指令,按理来说应该只执行第一条依赖关系,为什么除了clean的所有依赖关系都被执行了?

make会根据文件的依赖关系进行自动推导,以正确的顺序执行各个依赖关系

比如说一开始mybin缺少了test.o,于是make去makefile中查找,发现test.o:test.s的依赖关系可以生成test.o于是先执行该依赖关系。但是test.o:test.s的依赖关系缺少test.s,就再去找生成test.s的依赖关系,以此类推。

makefile语法

以上我们只简单讲解了一个基本的makefile例子,来帮助大家理解make,现在我们来讲解更多的makefile语法。

首先,在makefile中,指令内部的目标文件可以用$@代替,依赖文件列表可以用$^代替:

mybin:test.c
    gcc -o $@ $^  

在这里gcc -o $@ $^ gcc -o mybin test.c 是一样的。

变量

makefile中,是可以定义变量的,只需要用一个等号进行赋值即可:

bin=mybin
src=test.c

此时bin的值就是mybinsrc的值就是test.c,想要使用这个变量,就在对应的地方以$(变量名)的形式代替即可,这个变量可以放在任何地方,包括指令内部,依赖关系中等等。

比如下面这样:

bin=mybin
src=test.c

$(bin):$(src)
    gcc -o $(bin) $(src)

clean:
    rm -f $(bin)

任何需要test.cmybin的地方,都可以改为$(bin)$(src)


PHONY

讲解PHONY前,我们看到一个问题:

现在我们每次make都会生成一个mybin文件,如果直接gcc -o mybin test.c,那么新生成的mybin文件会覆盖原先的文件。但是make执行的指令,会进行一次检查,如果源文件test.c没有进行更新,那么make就会拒绝再次编译这个文件,因为编译出来的结果是一样的,导致mybin无法连续编译两次。

也就是上图中我们连续两次make,第二次拒绝了我们的原因。

PHONY在Makefile中是一个非常有用的特殊目标。当make执行到PHONY目标时,它会无条件执行该目标下定义的命令,而不会检查是否有同名的文件在。

因此我们就可以对mybin使用这个PHONY,让它强制执行命令,不论当前目录下有没有mybin。

修饰语法:

.PHONY:xxx

此时xxx对应的命令就会被强制执行。

makefile写法:

.PHONY:mybin
mybin:test.c
  gcc -o mybin test.c

此时mybin每次都会强制执行命令,不论之前是否存在mybin文件了。

但是这并不是PHONY的主要用途,其主要用于修饰伪目标。比如伪目标clean,如果当前目录下刚好有一个叫做clean的文件,那么clean作为一个目标文件,就有可能会被make禁止执行。可是我们的clean作为一个伪目标,其目的不是生成一个clean文件,而是执行命令,因此要用PHONY来强制执行clean对应的命令:

.PHONY: clean
clean:
    rm -rf *.o


相关文章
|
5天前
|
消息中间件 运维 Kubernetes
构建高效自动化运维体系:Ansible与Kubernetes的融合实践
【5月更文挑战第9天】随着云计算和微服务架构的普及,自动化运维成为确保系统可靠性和效率的关键。本文将深入探讨如何通过Ansible和Kubernetes的集成,构建一个强大的自动化运维体系。我们将分析Ansible的配置管理功能以及Kubernetes容器编排的优势,并展示如何将二者结合,以实现持续部署、快速扩展和高效管理现代云原生应用。文章还将涵盖实际案例,帮助读者理解在真实环境下如何利用这些工具优化运维流程。
|
19小时前
|
机器学习/深度学习 人工智能 运维
构建高效自动化运维系统:DevOps与AI的融合
【5月更文挑战第19天】 在数字化转型的浪潮中,企业IT运维面临着日益复杂的挑战。传统的手动运维方式已经无法满足快速迭代和高可靠性的需求。本文探讨了如何通过结合DevOps理念和人工智能(AI)技术,构建一个高效的自动化运维系统。文章首先回顾了DevOps的核心原则及其在自动化运维中的应用,接着分析了AI如何增强故障预测、智能决策和自动化流程的能力。最后,提出了一个综合DevOps与AI技术的自动化运维框架,并讨论了其在实际部署中的优势和潜在挑战。
|
1天前
|
机器学习/深度学习 人工智能 运维
构建高效自动化运维系统的五大关键步骤
【5月更文挑战第18天】在数字化转型的浪潮中,高效的自动化运维系统成为企业保障IT服务管理效率和稳定性的核心。本文将探讨构建自动化运维系统的五个关键步骤,包括需求分析、设计蓝图、选择合适的工具、实施与集成以及持续优化。通过这些步骤的实施,企业能够实现故障快速响应、资源优化配置和成本有效控制,从而提升整体的IT服务质量和用户满意度。
|
2天前
|
运维 监控 安全
构建高效自动化运维体系的五大支柱
【5月更文挑战第17天】 在当今IT基础设施管理领域,自动化不再是一个选择而是一个必然。本文将探讨构建高效自动化运维体系的核心要素,包括监控、配置管理、持续集成/持续部署(CI/CD)、故障响应以及安全策略的整合。通过深入分析这些关键组成部分,我们将揭示如何实现系统的稳定性、效率和安全性,同时减少人为错误并提升团队的响应能力。
|
4天前
|
缓存 IDE Java
Java一分钟之-Gradle:构建自动化工具
【5月更文挑战第16天】本文介绍了Gradle,一个基于Groovy的灵活构建工具,强调其优于Maven的灵活性和性能。文中通过示例展示了基本的`build.gradle`文件结构,并讨论了常见问题:版本冲突、缓存问题和构建速度慢,提供了相应的解决策略。此外,还提醒开发者注意插件ID、语法错误和源代码目录等易错点。掌握这些知识能提升开发效率,使构建过程更顺畅。
25 2
|
4天前
|
运维 监控 算法
构建高效自动化运维体系的实践与思考
【5月更文挑战第15天】 随着信息技术的飞速发展,企业对IT运维管理的要求越来越高。传统的手动运维已无法满足日益增长的业务需求,因此,构建一个高效、可靠且易于管理的自动化运维体系变得至关重要。本文将探讨在现代企业环境中,如何通过一系列策略和技术手段实现运维自动化,以及在此过程中可能遇到的挑战和解决方案。文章将基于实际案例分析,提供一种系统性的思考框架,帮助读者理解和构建适合自己的自动化运维体系。
|
5天前
|
运维 资源调度 监控
构建高效自动化运维流程的策略与实践
【5月更文挑战第15天】 在现代IT基础设施管理中,自动化运维已成为提高效率、确保稳定性和快速响应变化的关键。本文将探讨构建高效自动化运维流程的策略与实践,重点在于如何通过一系列切实可行的步骤实现从人工密集型到自动化驱动的转变。我们将讨论工具选择、流程设计、最佳实践以及持续改进的重要性,旨在帮助读者构建一个既灵活又可靠的自动化运维环境。
28 3
|
5天前
|
运维 监控 Kubernetes
构建高效自动化运维体系:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第15天】 随着云计算和微服务架构的普及,传统的IT运维模式面临转型压力。为提高软件交付效率并降低运维成本,本文探讨了利用容器技术实现自动化运维的有效策略。重点分析了在持续集成(CI)和持续部署(CD)流程中,容器如何发挥作用,以及它们如何帮助组织实现敏捷性和弹性。通过具体案例研究,文章展示了容器化技术在自动化测试、部署及扩展中的应用,并讨论了其对系统稳定性和安全性的影响。
|
5天前
|
Java Maven
Maven 自动化构建
**Maven自动化构建确保依赖稳定性:当bus-core-api(1.0-SNAPSHOT)构建完成时,自动触发app-web-ui(依赖1.0)的构建,保证上下游项目同步。**
|
5天前
|
运维 监控 安全
构建高效自动化运维系统:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第14天】 随着DevOps文化的深入人心,持续集成与持续部署(CI/CD)已成为现代软件工程不可或缺的组成部分。本文将探讨如何利用容器技术,尤其是Docker和Kubernetes,构建一个高效、可扩展的自动化运维系统。通过深入分析CI/CD流程的关键组件,我们将讨论如何整合这些组件以实现代码从提交到生产环境的快速、无缝过渡。文章还将涉及监控、日志管理以及安全性策略等运维考量,为读者提供一个全面的自动化运维解决方案蓝图。