GNU make 中文手册 第一二章 概述与介绍

news2024/12/27 2:12:27

一、第一章:概述

准备知识

在开始我们关于 make 的讨论之前,首先需要明确一些基本概念:

编译:把高级语言书写的代码,转换为机器可识别的机器指令。编译高级语言后生成的指令虽然可被机器识别,但是还不能被执行。编译时,编译器检查高级语言的语法、函数与变量的声明是否正确。只有所有的语法正确、相关变量定义正确,编译器就可以编译出中间目标文件。通常,一个高级语言的源文件都可对应一个目标文件。目标文件在 Linux 中默认后缀为 “.o”(如 “foo.c” 的目标文件为 “foo.o” )。为了和规则的目标文件相区别。本文将编译高级语言后生成的目标文件成为.o 文件。

链接:将多 .o 文件,或者 .o 文件和库文件链接成为可被操作系统执行的可执行程序(Linux 环境下,可执行文件的格式为 “ELF” 格式)。链接器不检查函数所在的源文件,只检查所有.o 文件中的定义的符号。将 .o 文件中使用的函数和其它 .o 或者库文件中的相关符号进行合并,对所有文件中的符号进行重新安排(重定位),并链接系统相关文件(程序启动文件等)最终生成可执行程序。链接过程使用 GNU 的 “ld” 工具。

静态库:又称为文档文件(Archive File)。它是多个 .o 文件的集合。Linux 中静态库文件的后缀为 “.a”。静态库中的各个成员(.o 文件)没有特殊的存在格式,仅仅是一个 .o 文件的集合。使用 “ar” 工具维护和管理静态库。

共享库:也是多个 .o 文件的集合,但是这些 .o 文件时有编译器按照一种特殊的方式生成(Linux 中,共享库文件格式通常为 “ELF” 格式。共享库已经具备了可执行条件)。模块中各个成员的地址(变量引用和函数调用)都是相对地址。使用此共享库的程序在运行时,共享库被动态加载到内存并和主程序在内存中进行连接。多个可执行程序可共享库文件的代码段(多个程序可以共享的使用库中的某一个模块,共享代码,不共享数据)。另外共享库的成员对象可被执行(由 libdl.so 提供支持)。

参考 info ld 了解更加详细的关于 ld 的说明和用法。


二、第二章 GNU make 介绍

2 GNU make 介绍

make 在执行时,需要一个命名为 Makefile 的文件。这个文件告诉 make 以何种方式编译源代码和链接程序。典型地,可执行文件可由一些 .o 文件按照一定的顺序生成或者更新。如果在你的工程中已经存在一个或者多个正确的 Makefile。当对工程中的若干源文件修改以后,需要根据修改来更新可执行文件或者库文件,正如前面提到的你只需要在 shell 下执行 “make”。make 会自动根据修改情况完成源文件的对应.o 文件的更新、库文件的更新、最终的可执行程序的更新。

make 通过比较对应文件(规则的目标和依赖,)的最后修改时间,来决定哪些文件需要更新、哪些文件不需要更新。对需要更新的文件 make 就执行数据库中所记录的相应命令(在 make 读取 Makefile 以后会建立一个编译过程的描述数据库。此数据库中记录了所有各个文件之间的相互关系,以及它们的关系描述)来重建它,对于不需要重建的文件 make 什么也不做。

而且可以通过 make 的命令行选项来指定需要重新编译的文件。可参考 9.2 指定终极目标 一节。


2.1 Makefile 简介

在执行 make 之前,需要一个命名为 Makefile 的特殊文件(本文的后续将使用 Makefile 作为这个特殊文件的文件名)来告诉 make 需要做什么(完成什么任务),该怎么做。通常,make 工具主要被用来进行工程编译和程序链接。

本节将分析一个简单的 Makefile,它对一个包含 8 个 C 的源代码和三个头文件的工程进行编译和链接。这个 Makefile 提供给了 make 必要的信息,make 程序根据 Makefile 中的规则描述执行相关的命令来完成指定的任务(如:编译、链接和清除编译过程文件等)。复杂的 Makefile 我们将会在本文后续进行讨论。

当使用 make 工具进行编译时,工程中以下几种文件在执行 make 时将会被编译(重新编译):

1. 所有的源文件没有被编译过,则对各个 C 源文件进行编译并进行链接,生成最后的可执行程序;

2. 每一个在上次执行 make 之后修改过的 C 源代码文件,在本次执行 make 时将会被重新编译;

3. 头文件在上一次执行 make 之后被修改。则所有包含此头文件的 C 源文件在本次执行 make 时将会被重新编译。

后两种情况是 make 只将修改过的 C 源文件重新编译生成 .o 文件,对于没有修改的文件不进行任何工作。重新编译过程中,任何一个源文件的修改,将产生新的对应的.o 文件,新的 .o 文件将和以前的已经存在、此次没有重新编译的.o 文件,重新连接生成最后的可执行程序。

首先让我们先来看一些 Makefile 相关的基本知识。


2.2 Makefile 规则介绍

一个简单的 Makefile 描述规则组成:

TARGET... : PREREQUISITES... 
	COMMAND 
	... 
	...

target:规则的目标。通常是最后需要生成的文件名或者为了实现这个目的而必需的中间过程文件名。可以是 .o文件、也可以是最后的可执行程序的文件名等。另外,目标也可以是一个 make 执行的动作的名称,如目标 “clean”,我们称这样的目标是 “伪目标”。参考4.6 Makefile伪目标 一节。

prerequisites:规则的依赖。生成规则目标所需要的文件名列表。通常一个目标依赖于一个或者多个文件。

command:规则的命令行。是规则所要执行的动作(任意的 shell 命令或者是可在 shell 下执行的程序)。它限定了 make 执行这条规则时所需要的动作。

一个规则可以有多个命令行,每一条命令占一行。注意:每一个命令行必须以 [Tab] 字符开始,[Tab] 字符告诉 make 此行是一个命令行。make 按照命令完成相应的动作。这也是书写 Makefile 中容易产生,而且比较隐蔽的错误。

命令就是在任何一个目标的依赖文件发生变化后重建目标的动作描述。一个目标可以没有依赖而只有动作(指定的命令)。比如 Makefile 中的目标 “clean”,此目标没有依赖,只有命令。它所定义的命令用来删除 make 过程产生的中间文件(进行清理工作)。

在 Makefile 中 “规则” 就是描述,在什么情况下、如何重建规则的目标文件,通常规则中包括了目标的依赖关系(目标的依赖文件)和重建目标的命令。make 执行重建目标的命令,来创建或者重建规则的目标(此目标文件也可以是触发这个规则的上一个规则中的依赖文件)。规则包含了文件之间的依赖关系,和更新此规则目标所需要的命令

一个 Makefile 文件中通常还包含了除规则以外的很多东西(后续我们会一步一步的展开)。一个最简单的 Makefile 可能只包含规则。规则在有些 Makefile 中可能看起来非常复杂,但是无论规则的书写是多么的复杂,它都符合规则的基本格式。

make 程序根据规则的依赖关系,决定是否执行规则所定义的命令的过程我们称之为执行规则。


2.3 简单的示例

本小节开始我们在第一小节中提到的例子。此例子由 3 个头文件和 8 个 C 文件组成。我们将书写一个简单的 Makefile,来描述如何创建最终的可执行文件 “edit”,此可执行文件依赖于8个C源文件和3个头文件。Makefile文件的内容如下:

edit : main.o kbd.o command.o display.o \
	insert.o search.o files.o utils.o 
	cc -o edit main.o kbd.o command.o display.o \
		insert.o search.o files.o utils.o 
main.o : main.c defs.h 
	cc -c main.c 
kbd.o : kbd.c defs.h command.h 
	cc -c kbd.c 
command.o : command.c defs.h command.h 
	cc -c command.c 
display.o : display.c defs.h buffer.h 
	cc -c display.c 
insert.o : insert.c defs.h buffer.h 
	cc -c insert.c 
search.o : search.c defs.h buffer.h 
	cc -c search.c 
files.o : files.c defs.h buffer.h command.h 
	cc -c files.c 
utils.o : utils.c defs.h 
	cc -c utils.c 
clean : 
	rm edit main.o kbd.o command.o display.o \
	insert.o search.o files.o utils.o


首先书写时,可以将一个较长行使用反斜线(\)来分解为多行,这样可以使我们的 Makefile 书写清晰、容易阅读理解。但需要注意:反斜线之后不能有空格(这也是大家最容易犯的错误,错误比较隐蔽)。我们推荐将一个长行分解为使用反斜线连接得多个行的方式。在完成了这个 Maekfile 以后;需要创建可执行程序 “edit”,所要做的就是在包含此 Makefile 的目录(当然也在代码所在的目录)下输入命令 “make”。删除已经此目录下之前使用 “make” 生成的文件(包括那些中间过程的 .o 文件),也只需要输入命令 “make clean” 就可以了。

在这个 Makefile 中,我们的目标(target)就是可执行文件 “edit” 和那些 .o文件(main.o,kbd.o….);依赖(prerequisites)就是冒号后面的那些 .c 文件和 .h 文件。所有的 .o 文件既是依赖(相对于可执行程序edit)又是目标(相对于.c 和 .h 文件)。命令包括 “cc –c maic.c”、“cc –c kbd.c”……

当规则的目标是一个文件,在它的任何一个依赖文件被修改以后,在执行 “make” 时,这个目标文件将会被重新编译或者重新连接。当然,此目标的任何一个依赖文件如果有必要则首先会被重新编译。在这个例子中,“edit” 的依赖为 8 个 .o 文件;而 “main.o” 的依赖文件为 “main.c” 和 “defs.h” 。当 “main.c” 或者 “defs.h” 被修改以后,再次执行 “make”,“main.o” 就会被更新(其它的 .o 文件不会被更新),同时 “main.o” 的更新将会导致 “edit” 被更新。

在描述依赖关系行之下,通常就是规则的命令行(存在一些些规则没有命令行),命令行定义了规则的动作(如何根据依赖文件,来更新目标文件)。命令行必需以 [Tab] 键开始,以和 Makefile 其他行区别。就是说所有的命令行必需以 [Tab] 字符开始,但并不是所有的以 [Tab] 键出现行都是命令行。但 make 程序会把出现在第一条规则之后的所有以 [Tab] 字符开始的行都作为命令行来处理。(记住:make 程序本身并不关心命令是如何工作的,对目标文件的更新需要你在规则描述中提供正确的命令。“make” 程序所做的就是当目标程序需要更新时,执行规则所定义的命令)。

目标 “clean” 不是一个文件,它仅仅代表执行一个动作的标识。正常情况下,不需要执行这个规则所定义的动作,因此目标 “clean” 没有出现在其它任何规则的依赖列表中。因此在执行 make 时,它所指定的动作不会被执行。除非在执行 make 时明确地指定它。而且目标 “clean” 没有任何依赖文件,它只有一个目的,就是通过这个目标名来执行它所定义的命令。Makefile 中把那些没有任何依赖,只有执行动作的目标,称为 “伪目标”(phony targets)。参考 4.6 Makefile 伪目标 一节。需要执行 “clean” 目标所定义的命令,可在shell下输入:make clean。


2.4 make 如何工作

默认的情况下,make 执行的是 Makefile 中的第一个规则,此规则的第一个目标称之为“最终目的”或者“终极目标”(就是一个 Makefile 最终需要更新或者创建的目标,参考9.2 指定终极目标 一节)。

上例的 Makefile,目标 “edit” 在 Makefile 中是第一个目标,因此它就是 make 的 “终极目标”。当修改了任何 C 源文件或者头文件后,执行 make 将会重建终极目标“edit”。

当在 shell 提示符下输入“make” 命令以后。make 读取当前目录下的 Makefile 文件,并将 Makefile 文件中的第一个目标作为其执行的“终极目标”,开始处理第一个规则(终极目标所在的规则)。在我们的例子中,第一个规则就是目标 “edit” 所在的规则。规则描述了 “edit” 的依赖关系,并定义了链接 .o 文件生成目标 “edit” 的命令; make 在执行这个规则所定义的命令之前,首先处理目标 “edit” 的所有的依赖文件(例子中的那些 .o 文件)的更新规则(以这些 .o 文件为目标的规则)。对这些 .o 文件为目标的规则处理有下列三种情况:

1. 目标.o 文件不存在,使用其描述规则创建它;

2. 目标 .o 文件存在,目标 .o 文件所依赖的.c 源文件、.h 文件中的任何一个比目标 .o 文件“更新”(在上一次 make 之后被修改)。则根据规则重新编译生成它;

3. 目标 .o 文件存在,目标.o 文件比它的任何一个依赖文件(的.c 源文件、.h 文件)“更新”(它的依赖文件在上一次 make 之后没有被修改),则什么也不做。

这些 .o 文件所在的规则之所以会被执行,是因为这些 .o 文件出现在“终极目标”的依赖列表中。在 Makefile 中一个规则的目标如果不是 “终极目标” 所依赖的(或者 “终极目标” 的依赖文件所依赖的),那么这个规则将不会被执行,除非明确指定执行这个规则(可以通过 make 的命令行指定重建目标,那么这个目标所在的规则就会被执行,例如 “make clean”)。在编译或者重新编译生成一个 .o 文件时,make 同样会去寻找它的依赖文件的重建规则(是这样一个规则:这个依赖文件在规则中作为目标出现),在这里就是 .c 和.h 文件的重建规则。在上例的 Makefile 中没有哪个规则的目标是 .c 或者 .h 文件,所以没有重建 .c 和 .h 文件的规则。不过 C 语言源程序文件可以使用工具 Bison 或者 Yacc 来生成(具体用法可参考相应的手册)。

完成了对 .o 文件的创建(第一次编译)或者更新之后,make 程序将处理终极目标 “edit” 所在的规则,分为以下三种情况:

1. 目标文件 “edit” 不存在,则执行规则,以创建目标 “edit”。

2. 目标文件 “edit” 存在,其依赖文件中有一个或者多个文件比它“更新”,则根据规则重新链接生成 “edit”。

3. 目标文件 “edit” 存在,它比它的任何一个依赖文件都“更新”,则什么也不做。

在这里插入图片描述

上例中,如果更改了源文件 “insert.c” 后执行 make,“insert.o” 将被更新,之后终极目标 “edit” 将会被重生成;如果我们修改了头文件 “command.h” 之后运行 “make”,那么 “kbd.o”、“command.o” 和 “files.o” 将会被重新编译,之后同样终极目标 “edit” 也将被重新生成。


以上我们通过一个简单的例子,介绍了 Makefile 中目标和依赖的关系。我们简单总结一下:
对于一个 Makefile 文件,“make” 首先解析终极目标所在的规则(上节例子中的第一个规则),根据其依赖文件(例子中第一个规则的 8 个.o 文件)依次(按照依赖文件列表从左到右的顺序)寻找创建这些依赖文件的规则。

首先为第一个依赖文件(main.o)寻找创建规则,如果第一个依赖文件依赖于其它文件(main.c、defs.h),则同样为这个依赖文件寻找创建规则(创建 main.c 和 defs.h 的规则,通常源文件和头文件已经存在,也不存在重建它们的规则)……,直到为所有的依赖文件找到合适的创建规则。之后 make 从最后一个规则(上例目标为 main.o 的规则)回退开始执行,最终完成终极目标的第一个依赖文件的创建和更新。

之后对第二个、第三个、第四个……终极目标的依赖文件执行同样的过程(上例的的顺序是“main.o”、“kbd.o”、“command.o”……)

创建或者更新每一个规则的依赖文件的过程,都是这样的一个过程(类似于 c 语言中的递归过程。对于任意一个规则执行的过程,都是按照依赖文件列表顺序,对于规则中的每一个依赖文件,使用同样方式(按照同样的过程)去重建它,在完成对所有依赖文件的重建之后,最后一步才是重建此规则的目标。

更新(或者创建)终极目标的过程中,如果任何一个规则执行出现错误, make 就立即报错并退出。整个过程 make 只是负责执行规则,而对具体规则所描述的依赖关系的正确性、规则所定义的命令的正确性不做任何判断。就是说,一个规则的依赖关系是否正确、描述重建目标的规则命令行是否正确,make 不做任何错误检查。

因此,需要正确的编译一个工程。需要在提供给 make 程序的 Makefile 中来保证其依赖关系的正确性、和执行命令的正确性。


2.5 指定变量

同样是上边的例子,我们来看一下终极目标 “edit” 所在的规则:

edit : main.o kbd.o command.o display.o \ 
     insert.o search.o files.o utils.o 
	cc -o edit main.o kbd.o command.o display.o \ 
		insert.o search.o files.o utils.o

在这个规则中,.o 文件列表出现了两次;第一次:作为目标 “edit” 的依赖文件列表出现,第二次:规则命令行中作为 “cc” 的参数列表。这样做所带来的问题是:如果我们需要为目标 “edit” 增加一个依赖文件,我们就需要在两个地方添加(依赖文件列表和规则的命令中)。添加时可能在 “edit” 的依赖列表中加入了、但却忘记了给命令行中添加,或者相反。这就给后期的维护和修改带来了很多不方便,添加或修改时出现遗漏。

为了避免这个问题,在实际工作中大家都比较认同的方法是,使用一个变量 “objects”、“OBJECTS”、“objs”、“OBJS”、“obj” 或者 “OBJ” 来作为所有的 .o 文件的列表的替代。在使用到这些文件列表的地方,使用此变量来代替。在上例的 Makefile 中我们可以添加这样一行:

objects = main.o kbd.o command.o display.o \ 
	insert.o search.o files.o utils.o

“objects” 作为一个变量,它代表所有的 .o 文件的列表。在定义了此变量后,我们
就可以在需要使用这些 .o 文件列表的地方使用 $(objects) 来表示它,而不需要罗列
所有的 .o 文件列表(变量可参考 第六章 使用变量)。因此上例的规则就可以这样写:

objects = main.o kbd.o command.o display.o \
	insert.o search.o files.o utils.o 

edit : $(objects)
	cc -o edit $(objects)

main.o : main.c defs.h 
	cc -c main.c 
kbd.o : kbd.c defs.h command.h 
	cc -c kbd.c 
command.o : command.c defs.h command.h 
	cc -c command.c 
display.o : display.c defs.h buffer.h 
	cc -c display.c 
insert.o : insert.c defs.h buffer.h 
	cc -c insert.c 
search.o : search.c defs.h buffer.h 
	cc -c search.c 
files.o : files.c defs.h buffer.h command.h 
	cc -c files.c 
utils.o : utils.c defs.h 
	cc -c utils.c 
clean : 
	rm edit $(objects) 

当我们需要为终极目标 “edit” 增加或者去掉一个 .o 依赖文件时,只需要改变 “objects”的定义(加入或者去掉若干个 .o 文件)。这样做不但减少书写的工作量,而且可以减少修改而产生错误的可能。


2.6 自动推导规则

在使用 make 编译 .c 源文件时,编译 .c 源文件规则的命令可以不用明确给出。这是因为 make 本身存在一个默认的规则,能够自动完成对 .c 文件的编译并生成对应的 .o 文件。它执行命令 “cc -c” 来编译 .c 源文件

在 Makefile 中我们只需要给出需要重建的目标文件名(一个 .o 文件),make 会自动为这个 .o 文件寻找合适的依赖文件(对应的 .c 文件。对应是指:文件名除后缀外,其余都相同的两个文件),而且使用正确的命令来重建这个目标文件。对于上边的例子,此默认规则就使用命令 “cc -c main.c -o main.o” 来创建文件 “main.o”。对一个目标文件是 “N.o”,依赖文件是 “N.c” 的规则,完全可以省略其规则的命令行,而由 make 自身决定使用默认命令。此默认规则称为 make 的隐含规则(关于隐含规则可参考 第十章 使用隐含规则)

这样,在书写 Makefile 时,我们就可以省略掉描述 .c 文件和 .o 依赖关系的规则,而只需要给出那些特定的规则描述( .o 目标所需要的 .h 文件)。因此上边的例子就可以以更加简单的方式书写,我们同样使用变量“ objects”。Makefile 内容如下:

objects = main.o kbd.o command.o display.o \
	insert.o search.o files.o utils.o 

edit : $(objects)
	cc -o edit $(objects)

main.o :  defs.h 
kbd.o :  defs.h command.h 
command.o :  defs.h command.h 
display.o :  defs.h buffer.h 
insert.o :  defs.h buffer.h 
search.o :  defs.h buffer.h 
files.o :  defs.h buffer.h command.h 
utils.o :  defs.h 

.PHONY : clean
clean : 
	rm edit $(objects) 

这种格式的 Makefile 更接近于我们实际应用。(关于目标 “clean” 的详细说明我们在后边。参考4.6 Makefile 伪目标 一节 和 5.4 命令的错误 一节)

make 的隐含规则在实际工程的 make 中会经常使用,它使得编译过程变得方便。几乎在所有的 Makefile 中都用到了 make 的隐含规则,make 的隐含规则是非常重要的一个概念。后续我们会在第十章会有专门的讨论。


2.7 另类风格的 makefile

上一节中我们提到过,Makefile 中,所有的 .o 目标文件都可以使用隐含规则由 make 自动重建,我们可以根据这一点书写更加简洁的 Makefile。而且在这个 Makefile 中,我们是根据依赖而不是目标对规则进行分组。形成另外一种风格的 Makefile。实现如下:

#sample Makefile 
objects = main.o kbd.o command.o display.o \ 
  insert.o search.o files.o utils.o 
edit : $(objects) 
	cc -o edit $(objects) 
$(objects) : defs.h 
kbd.o command.o files.o : command.h 
display.o insert.o search.o files.o : buffer.h

本例中,我们以三个头文件为出发点,对依赖于每一个头文件的目标进行合并。书写出一个多目标的规则,规则中多个目标同时依赖于对应的头文件,而且同一个文件可能同时存在多个规则中。例子中头文件 “defs.h” 作为所有 .o 文件的依赖文件。其它两个头文件作为规则所有目标文件(多个 .o 文件)的依赖文件。

这种风格的 Makefile 并不值得我们借鉴。问题在于:同时把多个目标文件的依赖放在同一个规则中进行描述(一个规则中含有多个目标文件),这样导致规则定义不明了,比较混乱。建议大家不要在 Makefile 中采用这种方式了书写。否则后期维护将会是一件非常痛苦的事情。

书写规则建议的方式是:单目标,多依赖。就是说尽量要做到一个规则中只存在一个目标文件,可有多个依赖文件。尽量避免使用多目标,单依赖的方式。 这样书写的好处是后期维护会非常方便,而且这样做会使 Makefile 会更清晰、明了。


2.8 清除工作目录过程文件

规则除了完成源代码编译之外,也可以完成其它任务。例如:前边提到的,为了实现清除当前目录中编译过程中产生的临时文件(edit 和那些 .o 文件)的规则:

clean : 
	rm edit $(objects)

在实际应用时,我们把这个规则写成如下稍微复杂一些的样子。以防止出现始料未及的情况。

.PHONY : clean 
clean : 
	-rm edit $(objects)

这两个实现有两点不同: 1. 通过 “.PHONY” 特殊目标,将 “clean” 目标声明为伪目标。避免当磁盘上存在一个名为 “clean” 文件时,目标 “clean” 所在规则的命令无法执行(参考 4.6 Makefile 伪目标 一节)。2. 在命令行之前使用 “-”,意思是忽略命令 “rm” 的执行错误(参考 5.4 命令的错误 一节)。

这样的一个目标在 Makefile 中,不能将其作为终极目标(Makefile 的第一个目标)。因为我们的初衷并不是,当你在命令行上输入 make 以后执行删除动作。而是要创建或者更新程序。在我们上边的例子中。就是在输入 make 以后需要对目标 “edit” 进行创建或者重建。

上例中因为目标 “clean” 没有出现在终极目标 “edit” 依赖关系中(终极目标的直接依赖或者间接依赖),所以我们执行 “make” 时,目标 “clean” 所在的规则将不会被处理。当需要执行此规则,要在 make 的命令行选项中明确指定这个目标(执行 “make clean”)。关于 make 的执行可参考 9.2 指定终极目标 一节。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/358071.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

小程序 npm sill idealTree buildDeps 安装一直没反应

目录 一、问题 二、解决 1、删除.npmsrc 、清除缓存 2、更换镜像源 3、最终检测 一、问题 记录:今天npm 一直安装不成功 显示:sill idealTree buildDeps 我的版本: 我百度到换镜像源安装方法,但我尝试后,依然…

CUDA性能指南

CUDA性能指南 文章目录CUDA性能指南5.1 整体性能优化策略5.2 最大化利用率5.2.1 应用程序层次5.2.2 设备层次5.2.3 多处理器层次5.2.3.1 占用率计算5.3 最大化存储吞吐量5.3.1 设备与主机之间的数据传输5.3.2 设备内存访问5.4最大化指令吞吐量5.4.1 算数指令5.4.2 控制流指令5.…

前端 ES6 环境下 require 动态引入图片以及问题

前端 ES6 环境下 require 动态引入图片以及问题require 引入图片方式打包体积对比总结ES6 环境中,通过 require 的方式引入图片很方便,一直以来也没有出过什么问题,后来项目中,需要动态引入图片。 require 动态引入也容易实现&am…

第一章 Kafka快速实战与基本原理

第一章 Kafka快速实战与基本原理 1、介绍 Kafka 是最初由 Linkedin 公司开发的,是一个分布式、支持分区的(partition)、多副本的(replica),基于 zookeeper 协调的分布式消息系统,它最大的特性就…

分布式(四)

五、分布式锁 1. 概念 1.1 本地锁 使用ReetrantLock类和synchronized关键字JDK自带的本地锁来控制一个JVM进程内的多个线程对本地共享资源的访问。 1.2 分布式锁 分布式系统下,不同的服务器/客户端通常运行在独立的JVM进程上。 多个JVM进程共享一份资源的话&…

leetcode 1~10 学习经历

LeetCode 习题 1 - 101. 两数之和2. 两数相加3. 无重复字符的最长子串4. 寻找两个正序数组的中位数5. 最长回文子串6. N 字形变换7. 整数反转8. 字符串转换整数 (atoi)9. 回文数10. 正则表达式匹配1. 两数之和 给定一个整数数组 nums 和一个整数目标值 target,请你在…

大数据处理学习笔记1.5 掌握Scala内建控制结构

文章目录零、本讲学习目标一、条件表达式(一)语法格式(二)执行情况(三)案例演示任务1、根据输入值的不同进行判断任务2、编写Scala程序,判断奇偶性二、块表达式(一)语法格…

科学推理~

科学推理 【物理】 1、力学 重力 重力并不是指向地心的,只有赤道可以 弹力 【重点】判断弹力方向 相互作用力 摩擦力 静摩擦力 滑动摩擦力 注意:最大静摩擦力默认等于滑动摩擦力 压强 固体压强 液体压强 连通器 气体压强 气体对外做功,T 下…

1 月份 NFT 行业报告

Jan.2023, DanielData Source: NFT Monthly Report1 月是近一年来代币价格最好的一个月,ETH、BTC 和 altcoins 的涨幅是 7 月以来最猛的。自然,这导致了 NFT 行业的交易量和市值增加。一些指标是可以预测的,比如已完成的投资轮数继…

BI知识全解,值得收藏

2021年度,中国商业软件市场的增长趋势是快速增长的,达到7.8亿美元,同比增长34.9%。商业智能BI在企业应用中具有巨大的价值,并逐渐成为现代企业信息化和数字化转型的基础。所以,全面了解BI,对于企业管理是非…

100天精通Python(数据分析篇)——第76天:Pandas数据类型转换函数pd.to_numeric(参数说明+实战案例)

文章目录专栏导读一、to_numeric参数说明0. 介绍1. arg1)接收列表2)接收一维数组3)接收Series对象2. errors1)errorscoerce2)errors ignore3. downcast1)downcastinteger2)downcastsigned3&…

Spring中bean的生命周期(通俗易懂)

具体流程 bean的生命周期分4个阶段:   1.实例化   2.属性赋值   3.初始化   4.销毁 实例化就是在内存中new()出一个对象,属性赋值就是给那些被Autowired修饰的属性注入对象,销毁是在Spring容器关闭时触发,初始化的步骤比较…

隐私计算头条周刊(2.13-2.19)

开放隐私计算收录于合集#企业动态44个#周刊合辑44个#政策聚焦37个#隐私计算91个#行业研究36个开放隐私计算开放隐私计算OpenMPC是国内第一个且影响力最大的隐私计算开放社区。社区秉承开放共享的精神,专注于隐私计算行业的研究与布道。社区致力于隐私计算技术的传播…

【JavaEE】Servlet学后大汇总

JavaEE之Servlet一、WEB容器二、Servlet常用API和简单说明三、Servlet生命周期Servlet对象是什么时候被创建的?Servlet被称为假单例一个请求对应一个request和一个response四、Servlet属性设置——三个范围(请求、会话、应用)五、会话、过滤器…

每日学术速递2.20

CV - 计算机视觉 | ML - 机器学习 | RL - 强化学习 | NLP 自然语言处理 Subjects: cs.CV 1.Boundary Guided Mixing Trajectory for Semantic Control with Diffusion Models 标题:用于扩散模型语义控制的边界引导混合轨迹 作者:Ye Zhu, Yu Wu, Zhi…

Android 开发布局笔记01 控件

Relative Layout 前端界面代码 <?xml version"1.0" encoding"utf-8"?> <RelativeLayout xmlns:android"http://schemas.android.com/apk/res/android"xmlns:app"http://schemas.android.com/apk/res-auto"xmlns:tools&qu…

数据结构与算法(Java版) | 线性结构和非线性结构

之前&#xff0c;我们说过&#xff0c;数据结构是算法的基础&#xff0c;因此接下来在这一讲我就要来给大家重点介绍一下数据结构了。 首先&#xff0c;大家需要知道的是&#xff0c;数据结构包括两部分&#xff0c;即线性结构和非线性结构。知道这点之后&#xff0c;接下来我…

flex一把梭

flex 使用display:flex&#xff0c;可以让一个元素变成弹性容器&#xff08;flex容器&#xff09;&#xff0c;该元素中的直接子元素成为弹性项&#xff08;flex项&#xff09; flex-direction 使用flex-direction可以控制flex容器的主轴的方向&#xff1a;垂直&#xff08;…

躬身入局,干货分享,2023年春招后端技术岗(Python)面试实战教程,Offer今始为君发

早春二月&#xff0c;研发倍忙&#xff0c;杂花生树&#xff0c;群鸥竟飞。为什么&#xff1f;因为春季招聘&#xff0c;无论是应届生&#xff0c;还是职场老鸟&#xff0c;都在摩拳擦掌&#xff0c;秣马厉兵&#xff0c;准备在面试场上一较身手&#xff0c;既分高下&#xff0…

Allegro如何让测量时显示双单位操作指导

Allegro如何让测量时显示双单位操作指导 在用Allegro做PCB设计的时候,时常会需要使用到测量命令,通常显示的一个单位,比如mil,如下图 当希望除了看到mil单位的值,又同时能够看到mm单位的值,省去换算的时间 具体设置如下 点击Setup点击User Preference