makefile 中文手册 第二章 _ GNU make介绍

makefile 中文手册 第二章 _ GNU make介绍
makefile 中文手册 第二章 _ GNU make介绍

第二章: GNU make 介绍

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

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

而且可以通过make的命令行选项来指定需要重新编译的文件。

Problems and Bugs

=================

If you have problems with GNU `make' or think you've found a bug, please report it to the developers; we cannot promise to do anything but we might well want to fix it.

Before reporting a bug, make sure you've actually found a real bug.Carefully reread the documentation and see if it really says you can do what you're trying to do. If it's not clear whether you should be able to do something or not, report that too; it's a bug in the documentation!

Before reporting a bug or trying to fix it yourself, try to isolate it to the smallest possible makefile that reproduces the problem. Then send us the makefile and the exact results `make' gave you, including any error or warning messages. Please don't paraphrase these messages: it's best to cut and paste them into your report. When generating this small makefile, be sure to not use any non-free or unusual tools in your commands: you can almost always emulate what such a tool would do with simple shell commands. Finally, be sure to explain what you expected to occur; this will help us decide whether the problem was really in the documentation.

Once you have a precise problem you can report it in one of two ways.Either send electronic mail to:

bug-make@https://www.360docs.net/doc/e617823585.html,

or use our Web-based project management tool, at:

https://www.360docs.net/doc/e617823585.html,/projects/make/

In addition to the information above, please be careful to include the version number of `make' you are using. You can get this information with the command `make --version'. Be sure also to include the type of machine and operating system you are using. One way to obtain this information is by looking at the final lines of output from the command `make --help'.

以上时GNU make的bug反馈方式。如果在你使用GNU make过程中。发现bug或者问题。可以通过以上的方式和渠道反馈。

好了。开始我们的神奇之旅吧!

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”,我们称这样的目标是“伪目标”。

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文件的内容如下:

#sample 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)。需要执行“clean”目标所定义的命令,可在shell下输入:make clean。

2.4make如何工作

默认的情况下,make执行的是Makefile中的第一个规则,此规则的第一个目标称之为“最终目的”或

者“终极目标”(就是一个Makefile最终需要更新或者创建的目标。

上例的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)

…….

…….

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内容如下:

# 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)

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”的详细说明我们在后边进行)

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

2.7 另类风格的makefile

Makefile中,目标使用隐含规则生成,我们就可以也可以书写另外一种风格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”目标声明为伪目标。避免当磁盘上存

背景: Board →ar7240(ap93) Cpu →mips 1、首先弄清楚什么是u-boot Uboot是德国DENX小组的开发,它用于多种嵌入式CPU的bootloader程序, uboot不仅支持嵌入式linux系统的引导,当前,它还支持其他的很多嵌入式操作系统。 除了PowerPC系列,还支持MIPS,x86,ARM,NIOS,XScale。 2、下载完uboot后解压,在根目录下,有如下重要的信息(目录或者文件): 以下为为每个目录的说明: Board:和一些已有开发板有关的文件。每一个开发板都以一个子目录出现在当前目录中,子目录存放和开发板相关的配置文件。它的每个子文件夹里都有如下文件(以ar7240/ap93为例): Makefile Config.mk Ap93.c 和板子相关的代码 Flash.c Flash操作代码 u-boot.lds 对应的链接文件 common:实现uboot命令行下支持的命令,每一条命令都对应一个文件。例如bootm命令对应就是cmd_bootm.c cpu:与特定CPU架构相关目录,每一款Uboot下支持的CPU在该目录下对应一个子目录,比如有子目录mips等。它的每个子文件夹里都有入下文件: Makefile Config.mk Cpu.c 和处理器相关的代码s Interrupts.c 中断处理代码 Serial.c 串口初始化代码 Start.s 全局开始启动代码 Disk:对磁盘的支持

Doc:文档目录。Uboot有非常完善的文档。 Drivers:Uboot支持的设备驱动程序都放在该目录,比如网卡,支持CFI的Flash,串口和USB等。 Fs:支持的文件系统,Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。 Include:Uboot使用的头文件,还有对各种硬件平台支持的汇编文件,系统的配置文件和对文件系统支持的文件。该目下configs目录有与开发板相关的配置文件,如 ar7240_soc.h。该目录下的asm目录有与CPU体系结构相关的头文件,比如说mips 对应的有asm-mips。 Lib_xxx:与体系结构相关的库文件。如与ARM相关的库放在lib_arm中。 Net:与网络协议栈相关的代码,BOOTP协议、TFTP协议、RARP协议和NFS文件系统的实现。 Tools:生成Uboot的工具,如:mkimage等等。 3、mips架构u-boot启动流程 u-boot的启动过程大致做如下工作: 1、cpu初始化 2、时钟、串口、内存(ddr ram)初始化 3、内存划分、分配栈、数据、配置参数、以及u-boot代码在内存中的位置。 4、对u-boot代码作relocate 5、初始化malloc、flash、pci以及外设(比如,网口) 6、进入命令行或者直接启动Linux kernel 刚一开始由于参考网上代码,我一个劲的对基于smdk2410的板子,arm926ejs的cpu看了N 久,启动过程和这个大致相同。 整个启动中要涉及到四个文件: Start.S →cpu/mips/start.S Cache.S →cpu/mips/cache.S Lowlevel_init.S →board/ar7240/common/lowlevel_init.S Board.c →lib_mips/board.c 整个启动过程分为两个阶段来看: Stage1:系统上电后通过汇编执行代码 Stage2:通过一些列设置搭建了C环境,通过汇编指令跳转到C语言执行. Stage1: 程序从Start.S的_start开始执行.(至于为什么,参考u-boot.lds分析.doc) 先查看start.S文件吧!~ 从_start标记开始会看到一长串莫名奇妙的代码:

LAMMPS手册-中文解析 一、 欧阳家百(2021.03.07) 二、简介 本部分大至介绍了LAMMPS的一些功能和缺陷。 1.什么是LAMMPS? LAMMPS是一个经典的分子动力学代码,他可以模拟液体中的粒子,固体和汽体的系综。他可以采用不同的力场和边界条件来模拟全原子,聚合物,生物,金属,粒状和粗料化体系。LAMMPS可以计算的体系小至几个粒子,大到上百万甚至是上亿个粒子。 LAMMPS可以在单个处理器的台式机和笔记本本上运行且有较高的计算效率,但是它是专门为并行计算机设计的。他可以在任何一个按装了C++编译器和MPI的平台上运算,这其中当然包括分布式和共享式并行机和Beowulf型的集群机。 LAMMPS是一可以修改和扩展的计算程序,比如,可以加上一些新的力场,原子模型,边界条件和诊断功能等。 通常意义上来讲,LAMMPS是根据不同的边界条件和初始条件对通过短程和长程力相互作用的分子,原子和宏观粒子集合对它们的牛顿运动方程进行积分。高效率计算的LAMMPS通过采用相邻清单来跟踪他们邻近的粒子。这些清单是根据粒子间的短程互拆力的大小进行优化过的,目的是防止局部粒子密度过高。在

并行机上,LAMMPS采用的是空间分解技术来分配模拟的区域,把整个模拟空间分成较小的三维小空间,其中每一个小空间可以分配在一个处理器上。各个处理器之间相互通信并且存储每一个小空间边界上的”ghost”原子的信息。LAMMPS(并行情况)在模拟3维矩行盒子并且具有近均一密度的体系时效率最高。 2.LAMMPS的功能 总体功能: 可以串行和并行计算 分布式MPI策略 模拟空间的分解并行机制 开源 高移植性C++语言编写 MPI和单处理器串行FFT的可选性(自定义) 可以方便的为之扩展上新特征和功能 只需一个输入脚本就可运行 有定义和使用变量和方程完备语法规则 在运行过程中循环的控制都有严格的规则 只要一个输入脚本试就可以同时实现一个或多个模拟任务 粒子和模拟的类型: (atom style命令) 原子 粗粒化粒子 全原子聚合物,有机分子,蛋白质,DNA

makefile新手教程 2013-11-08 本文翻译自https://www.360docs.net/doc/e617823585.html,/tutorials/ Makefiles --通过示例说明 编译源代码是沉闷的,尤其是当你想要include一些源代码,却又每次都需要手动敲编译命令的时候。 恩,我有个好消息告诉你...你用手敲命令行去编译的日子(基本上)一去不复返了,因为你将会学习如何编写Makefile。Makefile是配合make命令使用的特殊文件,make命令则会帮助你自动地、神奇般地管理你的工程。 这里你需要先准备以下文件: main.cpp

hello.cpp factorial.cpp functions.cpp 我建议你新建一个空的目录,然后将上述4个文件放入其中。

注意:我使用g++命令编译。你完全可以换成别的编译器 make工具 如果你运行make 它会去寻找当前目录下名字为makefile的文件,并按里面的内容执行。 如果你有很多makefile文件,那么可以用这个命令来执行: 当然还有其他的参数来使用make工具,详情请man make。 构建过程 1.编译器编译源代码文件,输出到目标文件 2.链接器将目标文件链接,并创建可执行文件 手动编译 手动编译并获得可执行文件,是一种琐碎的方式: 基本的Makefile

基本的makefile文件组成如下: 将此语法应用到我们的例子中,就是: all: g++ main.cpp hello.cpp factorial.cpp -o hello 我们将此文件保存为Makefile-1。要运行此makefile,则输入:make -f Makefile-1 在这个例子中可以看到,我们的target叫做all。这是makefile中的默认target。若无指定参数,make工具将按这个target 执行。 我们同时发现,这个例子中的target,也就是all,没有dependencies(依赖文件),因此make会安全地执行后续的system commands(系统命令)。 最后,make根据我们设定的命令完成了编译。 使用依赖文件 有时候使用多个不同的target会很有用,因为当你只修改了工程中的一个文件时,不必重新编译所有代码,只需要编译修改过的部分。比如:

嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处,谢请指正。 ?共享资源,欢迎转载:https://www.360docs.net/doc/e617823585.html, 一、移植环境 ?主机:VMWare--Fedora 9 ?开发板:Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器:arm-linux-gcc-4.3.2.tgz ?u-boot:u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括: ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程,如下图。

u-boot的stage1代码通常放在cpu/xxxx/start.S文件中,他用汇编语言写成;u-boot的stage2代码通常放在lib_xxxx/board.c文件中,他用C语言写成。各个部分的流程图如下:

2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持,可以查看board目录的一些子目录,如:board/samsung/目录下就是对三星一些ARM 处理器的支持,有smdk2400、smdk2410和smdk6400,但没有2440,所以我们就在这里建立自己的开发板项目。 1)因2440和2410的资源差不多,主频和外设有点差别,所以我们就在board/samsung/下建立自己开发板的项目,取名叫my2440 2)因2440和2410的资源差不多,所以就以2410项目的代码作为模板,以后再修改

手动建立makefile简单实例解析 假设我们有一个程序由5个文件组成,源代码如下:/*main.c*/ #include "mytool1.h" #include "mytool2.h" int main() { mytool1_print("hello mytool1!"); mytool2_print("hello mytool2!"); return 0; } /*mytool1.c*/ #include "mytool1.h" #include void mytool1_print(char *print_str) { printf("This is mytool1 print : %s ",print_str); } /*mytool1.h*/ #ifndef _MYTOOL_1_H #define _MYTOOL_1_H void mytool1_print(char *print_str); #endif /*mytool2.c*/ #include "mytool2.h" #include void mytool2_print(char *print_str) { printf("This is mytool2 print : %s ",print_str); }

/*mytool2.h*/ #ifndef _MYTOOL_2_H #define _MYTOOL_2_H void mytool2_print(char *print_str); #endif 首先了解一下make和Makefile。GNU make是一个工程管理器,它可以管理较多的文件。我所使用的RedHat 9.0的make版本为GNU Make version 3.79.1。使用make的最大好处就是实现了“自动化编译”。如果有一个上百个文件的代码构成的项目,其中一个或者几个文件进行了修改,make就能够自动识别更新了的文件代码,不需要输入冗长的命令行就可以完成最后的编译工作。make执行时,自动寻找Makefile(makefile)文件,然后执行编译工作。所以我们需要编写Makefile文件,这样可以提高实际项目的工作效率。 在一个Makefile中通常包含下面内容: 1、需要由make工具创建的目标体(target),通常是目标文件或可执行文件。 2、要创建的目标体所依赖的文件(dependency_file)。 3、创建每个目标体时需要运行的命令(command)。 格式如下: target:dependency_files command target:规则的目标。通常是程序中间或者最后需要生成的文件名,可以是.o文件、也可以是最后的可执行程序的文件名。另外,目标也可以是一个make执行的动作的名称,如目标“clean”,这样的目标称为“伪目标”。 dependency_files:规则的依赖。生成规则目标所需要的文件名列表。通常一个目标依赖于一个或者多个文件。 command:规则的命令行。是make程序所有执行的动作(任意的shell命令或者可在shell下执行的程序)。一个规则可以有多个命令行,每一条命令占一行。注意:每一个命令行必须以[Tab]字符开始,[Tab]字符告诉make此行是一个命令行。make按照命令完成相应的动作。这也是书写Makefile中容易产生,而且比较隐蔽的错误。命令就是在任何一个目标的依赖文件发生变化后重建目标的动作描述。一个目标可以没有依赖而只有动作(指定的命令)。比如Makefile中的目标“clean”,此目标没有依赖,只有命令。它所指定的命令用来删除make过程产生的中间文件(清理工作)。 在Makefile中“规则”就是描述在什么情况下、如何重建规则的目标文件,通常规则

实验十四Makefile工程管理器 14.1 编写包含多文件的Makefile 【实验内容】 编写一个包含多文件的Makefile。 【实验目的】 通过对包含多文件的Makefile的编写,熟悉各种形式的Makefile,并且进一步加深对Makefile中用户自定义变量、自动变量及预定义变量的理解。 【实验平台】 PC机、CentOS 5 操作系统、gcc等工具。 【实验步骤】 1.用vi在同一目录下编辑两个简单的Hello程序,如下所示: #hello.c #include "hello.h" int main() { printf("Hello everyone!\n"); } #hello.h #include 2.仍在同一目录下用vim编辑Makefile,不使用变量替换,用一个目标体实现(即直接将 hello.c和hello.h编译成hello目标体)。并用make验证所编写的Makefile是否正确。 3.将上述Makefile使用变量替换实现。同样用make验证所编写的Makefile是否正确 4.用编辑另一Makefile,取名为Makefile1,不使用变量替换,但用两个目标体实现(也 就是首先将hello.c和hello.h编译为hello.o,再将hello.o编译为hello),再用make 的‘-f’选项验证这个Makefile1的正确性。 5.将上述Makefile1使用变量替换实现 【详细步骤】 1.用vi打开上述两个代码文件…hello.c?和…hello.h? 2.在shell命令行中用gcc尝试编译,使用命令:…gcc hello.c -o hello?,并运行hello可执 行文件查看结果。 3.删除此次编译的可执行文件:rm –rf hello 4.用vim编辑Makefile,如下所示: hello:hello.c hello.h gcc hello.c -o hello 5.退出保存,在shell中键入:make查看结果 6.再次用vim打开Makefile,用变量进行替换,如下所示: OBJS :=hello.o CC :=gcc hello:$(OBJS) $(CC) $^ -o $@ 7.退出保存,在shell中键入:make查看结果

第六章:Makefile中的变量 -------------------------------------------------------------------------------- 在Makefile中,变量就是一个名字(像是C语言中的宏),代表一个文本字符串(变量的值)。在Makefile的目标、依赖、命令中引用一个变量的地方,变量会被它的值所取代(与C语言中宏引用的方式相同,因此其他版本的make也把变量称之为“宏”)。在Makefile中变量的特征有以下几点: 1. Makefile中变量和函数的展开(除规则的命令行以外),是在make读取makefile文件时进行的,这里的变量包括了使用“=”定义和使用指示符“define”定义的。 2. 变量可以用来代表一个文件名列表、编译选项列表、程序运行的选项参数列表、搜索源文件的目录列表、编译输出的目录列表和所有我们能够想到的事物。 3. 变量名是不包括“:”、“#”、“=”、前置空白和尾空白的任何字符串。需要注意的是,尽管在GNU make中没有对变量的命名有其它的限制,但定义一个包含除字母、数字和下划线以外的变量的做法也是不可取的,因为除字母、数字和下划线以外的其它字符可能会在以后的make版本中被赋予特殊含义,并且这样命名的变量对于一些shell来说不能作为环境变量使用。 4. 变量名是大小写敏感的。变量“foo”、“Foo”和“FOO”指的是三个不同的变量。Makefile 传统做法是变量名是全采用大写的方式。推荐的做法是在对于内部定义定义的一般变量(例如:目标文件列表objects)使用小写方式,而对于一些参数列表(例如:编译选项CFLAGS)采用大写方式,这并不是要求的。但需要强调一点:对于一个工程,所有Makefile中的变量命名应保持一种风格,否则会显得你是一个蹩脚的程序员(就像代码的变量命名风格一样)。 5. 另外有一些变量名只包含了一个或者很少的几个特殊的字符(符号)。称它们为自动化变量。像“$<”、“$@”、“$?”、“$*”等。 6.1 变量的引用 当我们定义了一个变量之后,就可以在Makefile的很多地方使用这个变量。变量的引用方式是:使用“$(VARIABLE_NAME)”或者“${ VARIABLE_NAME }”来引用一个变量的定义。例如:“$(foo) ”或者“${foo}”就是取变量“foo”的值。美元符号“$”在Makefile中有特殊的含义,所有在命令或者文件名中使用“$”时需要用两个美元符号“$$”来表示。对一个变量的引用可以在Makefile的任何上下文中,目标、依赖、命令、绝大多数指示符和新变量的赋值中。这里有一个例子,其中变量保存了所有.o文件的列表: objects = program.o foo.o utils.o program : $(objects) cc -o program $(objects)

windows下的makefile教程 https://www.360docs.net/doc/e617823585.html,/mirror_hc/archive/2008/03/26/2221117.aspx joeliu 制作4/19/2011 22:10:29 1. 先说几句废话 以前看书时经常遇到makefile,nmake这几个名词,然后随之而来的就是一大段莫名其妙的代码,把我看得云里雾里的。在图书馆和google上搜了半天,也只能找到一些零零星星的资料,把我一直郁闷得不行。最近因缘巧合,被我搞到了一份传说中的MASM6手册,终于揭开了NMAKE的庐山真面目。想到那些可能正遭受着同样苦难的同志以及那些看到E文就头晕的兄弟,所以就写了这篇文章。假如大家觉得有帮助的话,记得回复一下,当作鼓励!如果觉得很白痴,也请扔几个鸡蛋.本文是总结加翻译,对于一些关键词以及一些不是很确定的句子,保留了英文原版,然后再在括号里给出自己的理解以作参考。由于水平有限,加上使用NMAKE的经验尚浅,有不对的地方大家记得要指正唷。MASM6手册在AOGO(好像是)可以download,在我的BLOG上有到那的链接。 2. 关于NMAKE Microsoft Program Maintenance Utility,外号NMAKE,顾名思义,是用来管理程序的工具。其实说白了,就是一个解释程序。它处理一种叫做makefile的文件(以mak为后缀),解释里面的语句并执行相应的指令。我们编写makefile文件,按照规定的语法描述文件之间的依赖关系,以及与该依赖关系相关联的一系列操作。然后在调用NMAKE时,它会检查所有相关的文件,如果目标文件(target file,下文简称target,即依赖于其它文件的文件)的time stamp(就是文件最后一次被修改的时间,一个32位数,表示距离1980年以来经过的时间,以2秒为单位)小于依赖文件(dependent file,下文简称dependent,即被依赖的文件)的time stamp,NMAKE就执行与该依赖关系相关联的操作。请看下面这个例子:foo.exe : first.obj second.obj link first.obj,second.obj 第一行定义了依赖关系,称为dependency line;第二行给出了与该依赖关系相关联的操作,称为command line。因为foo.exe由first.obj和second.obj连接而成,所以说foo.exe依赖于first.ogj和second.obj,即foo.exe为target,first.obj和second.obj为dependent。如果first.obj和second.obj中的任何一个被修改了(其time stamp更大),则调用link.exe,重新连接生成foo.exe。这就是NMAKE的执行逻辑。 综上,NMAKE的核心就是这3个家伙——依赖关系,操作和判定逻辑(target.timestamp < dependent.timestamp,如果为true,就执行相应操作)。 3. MAKEFILE的语法 现在详细讨论一下makefile的语法。makefile就像一个玩具型的程序语言,麻雀虽小,但五脏具全。makefile的组成部分包括:描述语句(description block),推导规则(inference rules),宏和指令(directive)。 描述语句就是dependent lines和command lines的组合;推导规则就是预先定义好的或用户自己定义的依赖关系和关联命令;宏就不用说了吧;指令就是内定的一些可以被NMAKE识别的控制命令,提供了很多有用的功能。 3.1 特殊符号

Makefile结构分析 -----uClinux (2.6.x内核)系统映像过程 刘江欧阳昭暐吕熙隆 1、源代码文件及目录构成 解压缩uClinux-dist-20070130.tar.gz压缩文件,在uClinux-dist原始子目录下主要有:config、Bin、linux-2.4.x、linux-2.6.x 、lib、tools、Include、user和vendors,以及文件Makefile。另外,在编译后生成子目录images和romfs,以及文件autoconfig.h、config.in和两个隐含文件:.config和.depend。 config子目录包含文件及下一级子目录,如 config.in、configure.help、Fixconfig、Makefile、 Mkconfig、Setconfig所有这些文件及子目录 Scripts均与系统配置有关; linux-2.6.x子目录是嵌入式操作系统 uClinux-2.6.x的核心目录,包括下一级子目录 arch、include、init、drivers、fs、ipc、kernel、 lib、Mm、scripts和关键文件Makefile、 rules.make,编译后还要生成新文件romfs.o、linux 和system.map;lib子目录为嵌入式操作系统提供 压缩和改进了的函数库支持;tools子目录包含 romfs-inst.sh文件,通过调用此文件,可以把目录 或文件加入到romfs子目录中;user子目录包含各 种驱动程序文件目录,根据用户的配置情况,不同的 驱动程序会被编译进最后形成的操作系统中; vendors子目录包括与特定硬件平台相关的分类目录 组。目录结构如图1所示。 Makefile的详细介绍情况在 uClinux-dist\linux-2.6.x\Documentation\kbuil d中,如图2所示。图1、目录结构即Linux 内核中的 Makefile 以及与 Makefile 直接相关的文件有:

Linux如何写makefile文件 关于程序的编译和链接 —————————— 在此,我想多说关于程序编译的一些规范和方法,一般来说,无论是C、C++、还是pas,首先要把源文件编译成中间代码文件,在Windows下也就是 .obj 文件,UNIX下是 .o 文件,即 Object File,这个动作叫做编译(compile)。然后再把大量的Object File合成执行文件,这个动作叫作链接(link)。 编译时,编译器需要的是语法的正确,函数与变量的声明的正确。对于后者,通常是你需要告诉编译器头文件的所在位置(头文件中应该只是声明,而定义应该放在 C/C++文件中),只要所有的语法正确,编译器就可以编译出中间目标文件。一般来说,每个源文件都应该对应于一个中间目标文件(O文件或是OBJ文 件)。 链接时,主要是链接函数和全局变量,所以,我们可以使用这些中间目标文件(O文件或是OBJ文件)来链接我们的应用程序。链接器并不管函数所在的源文件, 只管函数的中间目标文件(Object File),在大多数时候,由于源文件太多,编译生成的中间目标文件太多,而在链接时需要明显地指出中间目标文件名,这对于编译很不方便,所以,我们要给 中间目标文件打个包,在Windows 下这种包叫“库文件”(Library File),也就是 .lib 文件,在UNIX下,是Archive File,也就是 .a 文件。 总结一下,源文件首先会生成中间目标文件,再由中间目标文件生成执行文件。在编译时,编译器只检测程序语法,和函数、变量是否被声明。如果函数未被声明, 编译器会给出一个警告,但可以生成Object File。而在链接程序时,链接器会在所有的Object File中找寻函数的实现,如果找不到,那到就会报链接错误码(Linker Error),在VC下,这种错误一般是:Link 2001错误,意思说是说,链接器未能找到函数的实现。你需要指定函数的Object File. 好,言归正传,GNU的make有许多的内容,闲言少叙,还是让我们开始吧。 Makefile 介绍 ——————— make命令执行时,需要一个 Makefile 文件,以告诉make命令需要怎么样的去编译和链接程序。 首先,我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册,在这个示例中,我们的工程有 8

AM335x uboot spl分析 芯片到uboot启动流程 ROM → SPL→ uboot.img 简介 在335x 中ROM code是第一级的bootlader。mpu上电后将会自动执行这里的代码,完成部分初始化和引导第二级的bootlader,第二级的bootlader引导第三级bootader,在 ti官方上对于第二级和第三级的bootlader由uboot提供。 SPL To unify all existing implementations for a secondary program loader (SPL) and to allow simply adding of new implementations this generic SPL framework has been created. With this framework almost all source files for a board can be reused. No code duplication or symlinking is necessary anymore. 1> Basic ARM initialization 2> UART console initialization 3> Clocks and DPLL locking (minimal) 4> SDRAM initialization 5> Mux (minimal) 6> BootDevice initialization(based on where we are booting from.MMC1/MMC2/Nand/Onenand) 7> Bootloading real u-boot from the BootDevice and passing control to it. uboot spl源代码分析 一、makefile分析 打开spl文件夹只有一个makefile 可见spl都是复用uboot原先的代码。 主要涉及的代码文件为u-boot-2011.09-psp04.06.00.03/arch/arm/cpu/armv7 u-boot-2011.09-psp04.06.00.03/arch/arm/lib u-boot-2011.09-psp04.06.00.03/drivers LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-spl.lds 这个为链接脚本 __image_copy_end _end 三、代码解析 __start 为程序开始(arch/arm/cpu/armv7/start.S) .globl _start 这是在定义u-boot的启动定义入口点,汇编程序的缺省入口是 start 标号,用户也可以在连接脚本文件中用ENTRY标志指明其它入口点。

Makefile 语法分析第一部分 VERSION = 2 # 给变量VERSION赋值 PATCHLEVEL = 6 # 给变量PATCHLEVEL赋值 SUBLEVEL = 22 # 给变量SUBLEVEL赋值 EXTRAVERSION = .6 # 给变量EXTRAVERSION赋值 NAME = Holy Dancing Manatees, Batman! # 给变量NAME赋值 # *DOCUMENTATION* # To see a list of typical targets execute "make help" # More info can be located in ./README # Comments in this file are targeted only to the developer, do not # expect to learn how to build the kernel reading this file. # Do not: # o use make's built-in rules and variables # (this increases performance and avoid hard-to-debug behavour); # o print "Entering directory ..."; MAKEFLAGS += -rR --no-print-directory # 操作符“+=”的作用是给变量(“+=”前面的MAKEFLAGS)追加值。 # 如果变量(“+=”前面的MAKEFLAGS)之前没有定义过,那么,“+=”会自动变成“=”; # 如果前面有变量(“+=”前面的MAKEFLAGS)定义,那么“+=”会继承于前次操作的赋值符;# 如果前一次的是“:=”,那么“+=”会以“:=”作为其赋值符 # 在执行make时的命令行选项参数被通过变量“MAKEFLAGS”传递给子目录下的make程序。# 对于这个变量除非使用指示符“unexport”对它们进行声明,它们在整个make的执行过程中始终被自动的传递给所有的子make。 # 还有个特殊变量SHELL与MAKEFLAGS一样,默认情况(没有用“unexport”声明)下在整个make的执行过程中被自动的传递给所有的子make。 # # -rR --no-print-directory # -r disable the built-in impilict rules. # -R disable the built-in variable setttings. # --no-print-directory。 # We are using a recursive build, so we need to do a little thinking # to get the ordering right. # # Most importantly: sub-Makefiles should only ever modify files in # their own directory. If in some directory we have a dependency on # a file in another dir (which doesn't happen often, but it's often # unavoidable when linking the built-in.o targets which finally # turn into vmlinux), we will call a sub make in that other dir, and

Makefile经典教程 0 Makefile概述 (2) 0.1关于程序的编译和链接 (2) 1 Makefile介绍 (3) 1.1 Makefile的规则 (4) 1.2一个示例 (4) 1.3 make是如何工作的 (6) 1.4 makefile中使用变量 (7) 1.5让make自动推导 (8) 1.6另类风格的makefile (9) 1.7清空目标文件的规则 (10) 2 Makefile总述 (11) 2.1 Makefile里有什么? (11) 2.2Makefile的文件名 (12) 2.3引用其它的Makefile (12) 2.4环境变量MAKEFILES (13) 2.5 make的工作方式 (13) 3 Makefile书写规则 (14) 3.1规则举例 (14) 3.2规则的语法 (14) 3.3在规则中使用通配符 (15) 3.4文件搜寻 (16) 3.5伪目标 (17) 3.6多目标 (19) 3.7静态模式 (20) 3.8自动生成依赖性 (22) 4 Makefile书写命令 (24) 4.1显示命令 (24) 4.2命令执行 (25) 4.3命令出错 (25) 4.4嵌套执行make (26) 4.5定义命令包 (29) 1

0 Makefile概述 什么是makefile?或许很多Winodws的程序员都不知道这个东西,因为那些Windows的IDE都为你做了这个工作,但我觉得要作一个好的和professional的程序员,makefile还是要懂。这就好像现在有这么多的HTML的编辑器,但如果你想成为一个专业人士,你还是要了解HTML的标识的含义。特别在Unix下的软件编译,你就不能不自己写makefile了,会不会写makefile,从一个侧面说明了一个人是否具备完成大型工程的能力。 因为,makefile关系到了整个工程的编译规则。一个工程中的源文件不计数,其按类型、功能、模块分别放在若干个目录中,makefile定义了一系列的规则来指定,哪些文件需要先编译,哪些文件需要后编译,哪些文件需要重新编译,甚至于进行更复杂的功能操作,因为makefile就像一个Shell脚本一样,其中也可以执行操作系统的命令。 makefile带来的好处就是——“自动化编译”,一旦写好,只需要一个make命令,整个工程完全自动编译,极大的提高了软件开发的效率。make是一个命令工具,是一个解释makefile中指令的命令工具,一般来说,大多数的IDE都有这个命令,比如:Delphi的make,Visual C++的nmake,Linux下GNU的make。可见,makefile都成为了一种在工程方面的编译方法。 现在讲述如何写makefile的文章比较少,这是我想写这篇文章的原因。当然,不同产商的make各不相同,也有不同的语法,但其本质都是在“文件依赖性”上做文章,这里,我仅对GNU的make进行讲述,我的环境是RedHat Linux 8.0,make的版本是3.80。必竟,这个make是应用最为广泛的,也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的(POSIX.2)。 在这篇文档中,将以C/C++的源码作为我们基础,所以必然涉及一些关于C/C++的编译的知识,相关于这方面的内容,还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。 0.1关于程序的编译和链接 在此,我想多说关于程序编译的一些规范和方法,一般来说,无论是C、C++、还是pas,首先要把源文件编译成中间代码文件,在Windows下也就是.obj 文件,UNIX

uboot版本文件结构的更新改变 分类:ARM2011-09-22 12:57 339人阅读评论(0) 收藏举报本来是开始分析uboot代码的,但是无论是教材还是网上资料都对于我最新下的uboot原码结构不同,对于还是小白的我不容易找到相应的文件,下面是uboot版本中文件组织结构的改变,,,,, u-boot版本情况 网站:http://ftp.denx.de/pub/u-boot/ 1、版本号变化: 2008年8月及以前 按版本号命名:u-boot-1.3.4.tar.bz2(2008年8月更新) 2008年8月以后均按日期命名。 目前最新版本:u-boot-2011.06.tar.bz2(2011年6月更新) 2、目录结构变化: u-boot目录结构主要经历过2次变化,u-boot版本第一次从u-boot-1.3.2开始发生变化,主要增加了api的内容;变化最大的是第二次,从2010.6版本开始。 u-boot-2010.03及以前版本 ├── api存放uboot提供的接口函数 ├── board根据不同开发板定制的代码,代码也不少 ├── common通用的代码,涵盖各个方面,已命令行处理为主 ├── cpu与体系结构相关的代码,uboot的重头戏 ├── disk磁盘分区相关代码 ├── doc文档,一堆README开头的文件 ├── drivers驱动,很丰富,每种类型的设备驱动占用一个子目录 ├── examples示例程序 ├── fs文件系统,支持嵌入式开发板常见的文件系统 ├── include头文件,已通用的头文件为主 ├── lib_【arch】与体系结构相关的通用库文件 ├── nand_spl NAND存储器相关代码 ├── net网络相关代码,小型的协议栈 ├── onenand_ipl

目录 一:Makefile基本规则 1.1示例 1.2 隐式规则 1.3 伪目标 1.4 搜索源文件 二:变量 2.1使用变量定义变量值 2.2追加变量 三:条件判断 四:函数

Linux下Makefile总结 ——一步 MakeFile可以看做是一种简单的编程语言,其诞生的本质目的是实现自动化编译。 以Linux下gcc-c编译器为例,编译一个c语言程序需要经过以下几个步骤: 1.将c语言源程序预处理,生成.i文件; 2.预处理后的.i语言编译成汇编语言,生成.s文件; 3.汇编语言经过汇编,生成目标文件.o文件; 4.将各个模块的.o文件链接起来,生成一个可执行程序文件。 我们知道,在Visual C++6.0中,可以新建一个工程,在一个工程当中能够包含若干个c语言文件,则编译的时候直接编译整个工程便可。Linux下无法为多个c语言文件新建工程,但可以通过MakeFile实现它们的整合编译。 如上gcc-c编译步骤,如果使用Makefile则过程为: .C文件——>.o文件——>可执行文件 当然,Makefile中也加入了自己的设置变量方法与集成了一些函数,能够更有效地方便用户使用。 /**************************分隔符********************************/

一:Makefile基本规则 1.1示例 target ... : prerequisites ... command ... ... target也就是一个目标文件,可以是Object File,也可以是执行文件。prerequisites就是,要生成那个target所需要的文件或是目标。command也就是make需要执行的命令。(任意的Shell命令) 为了方便理解,我们来看一个示例: /*Makefile示例*/ edit : main.o kbd.o command.o display.o / insert.o search.o files.o utils.o gcc -o edit main.o kbd.o command.o display.o / insert.o search.o files.o utils.o main.o : main.c defs.h #生成main.o gcc -c main.c

/* * *Purpose: the document is used to learn detailed information aboutimx51 cpu start.S, *referring to some documents on websites. *file address: U-boot-2009.08/Cpu/Arm_cortexa8/start.S * * writer: xfhai 2011.7.22 * *Instruction: *1.@xxxx : indicates annotation *2./***** *** *****/ : stand for code in my files *3.instructions refers to code not included in my file * */ Section 1: uboot overview 大多数bootloader都分为stage1和stage2两部分,u-boot也不例外。依赖于CPU体系结构的代码(如设备初始化代码等)通常都放在stage1且可以用汇编语言来实现,而stage2则通常用C语言来实现,这样可以实现复杂的功能,而且有更好的可读性和移植性。 1、Stage1 start.S代码结构 u-boot的stage1代码通常放在start.S文件中,他用汇编语言写成,其主要代码部分如下:==> (1)定义入口。由于一个可执行的Image必须有一个入口点,并且只能有一个全局入口,通常这个入口放在ROM(Flash)的0x0地址,因此,必须通知编译器以使其知道这个入口,该工作可通过修改连接器脚本来完成。 ==>(2)设置异常向量(Exception Vector)。 ==>(3)设置CPU的速度、时钟频率及终端控制寄存器。 ==>(4)初始化内存控制器。 ==>(5)将ROM中的程序复制到RAM中。 ==>(6)初始化堆栈。 ==>(7)转到RAM中执行,该工作可使用指令ldr pc来完成。 2、Stage2 C语言代码部分 lib_arm/board.c中的start arm boot是C语言开始的函数也是整个启动代码中C语言的主函数,同时还是整个u-boot(armboot)的主函数,该函数只要完成如下操作: ==>(1)调用一系列的初始化函数。 ==>(2)初始化Flash设备。 ==>(3)初始化系统内存分配函数。 ==>(4)如果目标系统拥有NAND设备,则初始化NAND设备。 ==>(5)如果目标系统有显示设备,则初始化该类设备。 ==>(6)初始化相关网络设备,填写IP、MAC地址等。 ==>(7)进去命令循环(即整个boot的工作循环),接受用户从串口输入的命令,然后进行相应的工作。

相关文档
最新文档