Board logo

标题: Nios II IDE软件编译环境探密之（一）[转帖] [打印本页]
作者: JOHN    时间: 2005-10-18 15:26     标题: Nios II IDE软件编译环境探密之（一）[转帖]

Nios II IDE编译环境提供了许多工程模板帮助用户尽可能的快速的推出可运行的系统，可是当我们用一种模板生成应用环境后，需要增加其他应用模式的时候就会遇到问题，我们有必要对Nios II IDE的编译环境有一个了解，使我们灵活的去配置编译系统，下面介绍的内容对于熟悉LINUX系统编程的开发者可能很熟悉，希望我们一起来分析Nios II IDE编译的细节，它的编译环境还是很精巧的哦，谬误之处请斧正。
     首先我整理了一份GNU MAKE的资料，阅读它能为我们了解Nios II IDE的编译环境提供基础。   
GNU make 和 makefile
   ·         GNU make
·         makefile 基本结构
·         makefile 变量
·         GNU make 的主要预定义变量
·         隐含规则
·         makefile 范例
·         运行 make
1.       GNU make
    在大型的开发项目中，通常有几十到上百个的源文件，如果每次均手工键入 gcc 命令进行编译的话，则会非常不方便。因此，人们通常利用 make 工具来自动完成编译工作。这些工作包括：如果仅修改了某几个源文件，则只重新编译这几个源文件；如果某个头文件被修改了，则重新编译所有包含该头文件的源文件。利用这种自动编译可大大简化开发工作，避免不必要的重新编译。实际上，make 工具通过一个称为 makefile 的文件来完成并自动维护编译工作。makefile 需要按照某种语法进行编写，其中说明了如何编译各个源文件并连接生成可执行文件，并定义了源文件之间的依赖关系。当修改了其中某个源文件时，如果其他源文件依赖于该文件，则也要重新编译所有依赖该文件的源文件。makefile 文件是许多编译器，包括 Windows NT 下的编译器维护编译信息的常用方法，只是在集成开发环境中，用户通过友好的界面修改 makefile 文件而已。
    默认情况下，GNU make 工具在当前工作目录中按如下顺序搜索 makefile：
* GNUmakefile
* makefile
* Makefile
在 UNIX 系统中，习惯使用 Makefile 作为 makfile 文件。如果要使用其他文件作为 makefile，则可利用类似下面的 make 命令选项指定 makefile 文件：
$ make -f Makefile.debug

2.       makefile 基本结构
makefile 中一般包含如下内容：
* 需要由 make 工具创建的项目，通常是目标文件和可执行文件。通常使用“目标（target）”一词来表示要创建的项目。
* 要创建的项目依赖于哪些文件。
* 创建每个项目时需要运行的命令。

例如，假设你现在有一个 C++ 源文件 test.C，该源文件包含有自定义的头文件 test.h，则目标文件 test.o
明确依赖于两个源文件：test.C 和 test.h。另外，你可能只希望利用 g++ 命令来生成 test.o 目标文件。
这时，就可以利用如下的 makefile 来定义 test.o 的创建规则：

# This makefile just is a example.
# The following lines indicate how test.o depends
# test.C and test.h, and how to create test.o

test. test.C test.h
    g++ -c -g test.C

从上面的例子注意到，第一个字符为 # 的行为注释行。第一个非注释行指定 test.o 为目标，并且依赖于test.C 和 test.h 文件。随后的行指定了如何从目标所依赖的文件建立目标。当 test.C 或 test.h 文件在编译之后又被修改，则 make 工具可自动重新编译 test.o，如果在前后两次编译之间，test.C 和 test.h 均没有被修改，而且 test.o 还存在的话，就没有必要重新编译。这种依赖关系在多源文件的程序编译中尤其重要。通过这种依赖关系的定义，make 工具可避免许多不必要的编译工作。当然，利用 Shell 脚本也可以达到自动编译的效果，但是，Shell 脚本将全部编译任何源文件，包括哪些不必要重新编译的源文件，而 make 工具则可根据目标上一次编译的时间和目标所依赖的源文件的更新时间而自动判断应当编译哪个源文件。
一个 makefile 文件中可定义多个目标，利用 make target 命令可指定要编译的目标，如果不指定目标，则使用第一个目标。通常，makefile 中定义有 clean 目标，可用来清除编译过程中的中间文件，例如：
clean:
    rm -f *.o
运行 make clean 时，将执行 rm -f *.o 命令，最终删除所有编译过程中产生的所有中间文件。

3.       makefile 变量
GNU 的 make 工具除提供有建立目标的基本功能之外，还有许多便于表达依赖性关系以及建立目标的命令的特
色。其中之一就是变量或宏的定义能力。如果你要以相同的编译选项同时编译十几个 C 源文件，而为每个目
标的编译指定冗长的编译选项的话，将是非常乏味的。但利用简单的变量定义，可避免这种乏味的工作：

# Define macros for name of compiler
CC = gcc

# Define a macr o for the CC flags
CCFLAGS = -D_DEBUG -g -m486

# A rule for building a object file
test. test.c test.h
    $(CC) -c $(CCFLAGS) test.c

在上面的例子中，CC 和 CCFLAGS 就是 make 的变量。GNU make 通常称之为变量，而其他 UNIX 的 make
工具称之为宏，实际是同一个东西。在 makefile 中引用变量的值时，只需变量名之前添加 $ 符号，如
上面的 $(CC) 和 $(CCFLAGS)。

4.       GNU make 的主要预定义变量
GNU make 有许多预定义的变量，这些变量具有特殊的含义，可在规则中使用。表 1-5 给出了一些主要的
预定义变量，除这些变量外，GNU make 还将所有的环境变量作为自己的预定义变量。

                        表 1-5  GNU make 的主要预定义变量
预定义变量                      含义
$*              不包含扩展名的目标文件名称。
$+              所有的依赖文件，以空格分开，并以出现的先后为序，可能包含重复              的依赖文件。
$<              第一个依赖文件的名称。
$?              所有的依赖文件，以空格分开，这些依赖文件的修改日期比目标的创                建日期晚。
$@              目标的完整名称。
$^              所有的依赖文件，以空格分开，不包含重复的依赖文件。
$%              如果目标是归档成员，则该变量表示目标的归档成员名称。例如，如                果目标名称
                为 mytarget.so(image.o)，则 $@ 为 mytarget.so，而 $% 为                  image.o。
AR              归档维护程序的名称，默认值为 ar。
ARFLAGS         归档维护程序的选项。
AS              汇编程序的名称，默认值为 as。
ASFLAGS         汇编程序的选项。
CC              C 编译器的名称，默认值为 cc。
CFLAGS          C 编译器的选项。
CPP             C 预编译器的名称，默认值为 $(CC) -E。
CPPFLAGS        C 预编译的选项。
CXX             C++ 编译器的名称，默认值为 g++。
CXXFLAGS        C++ 编译器的选项。
FC              FORTRAN 编译器的名称，默认值为 f77。
FFLAGS          FORTRAN 编译器的选项。

5.       隐含规则
GNU make 包含有一些内置的或隐含的规则，这些规则定义了如何从不同的依赖文件建立特定类型的目标。
GNU make 支持两种类型的隐含规则：
* 后缀规则（Suffix Rule）。后缀规则是定义隐含规则的老风格方法。后缀规则定义了将一个具有某个后缀的文件（例如，.c 文件）转换为具有另外一种后缀的文件（例如，.o 文件）的方法。每个后缀规则以两个成对出现的后缀名定义，例如，将 .c 文件转换为 .o 文件的后缀规则可定义为：

.c.
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

* 模式规则（pattern rules）。这种规则更加通用，因为可以利用模式规则定义更加复杂的依赖性规则。
模式规则看起来非常类似于正则规则，但在目标名称的前面多了一个 % 号，同时可用来定义目标和依赖
文件之间的关系，例如下面的模式规则定义了如何将任意一个 X.c 文件转换为 X.o 文件：

%.c:%.o
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

6.       makefile 范例
#SAMPLE#
CCE 的 Makefile

7.       运行 make
我们知道，直接在 make 命令的后面键入目标名可建立指定的目标，如果直接运行 make，则建立第一个目标。我们还知道可以用 make -f mymakefile 这样的命令指定 make 使用特定的 makefile，而不是默认的 GNUmakefile、makefile 或 Makefile。但 GNU make 命令还有一些其他选项，表 1-6 给出了这些选项。

                        表 1-6  GNU make 命令的常用命令行选项

命令行选项              含义
-C DIR              在读取 makefile 之前改变到指定的目录 DIR。
-f FILE             以指定的 FILE 文件作为 makefile。
-h                  显示所有的 make 选项。
-i                  忽略所有的命令执行错误。
-I DIR              当包含其他 makefile 文件时，可利用该选项指定搜索目录。
-n                  只打印要执行的命令，但不执行这些命令。
-p                  显示 make 变量数据库和隐含规则。
-s                  在执行命令时不显示命令。
-w                  在处理 makefile 之前和之后，显示工作目录。
-W FILE             假定文件 FILE 已经被修改。


[此贴子已经被作者于2005-10-18 15:26:20编辑过]

作者: JOHN    时间: 2005-10-18 15:27

Nios II IDE软件编译环境探密之（二）
在Nios II IDE软件编译环境探密之（一）中我们了解了GNU MAKE和Makefile的相关知识，我们知道NIOS II IDE中集成了GNU C/C++编译环境（具体位置在C:\altera\kits\nios2\bin\nios2-gnutools，我的系统默认安装在C:盘上），Nios II IDE编译环境会为用户项目自动生成一个基于用户特定系统配置（SOPC Builder生成的PTF文件）的Makefile文件，Nios II IDE的编译/连接设置的任何改变都会映射到这个自动生成文件中，这个文件注明：THIS IS AN AUTO-GENERATED FILE. DO NOT EDIT DIRECTLY。用户不需直接修改，对编译系统的修改在Makefile文件中注明：
To change the settings in here:
#  - Right click on the project
#  - Select "roperties" option
#  - Use property pages to set options. Details given below
在这个自动生成的Makefile文件中我们看到设置了几个重要的宏变量，但具体的编译规则不在这个文件中出现，我们在下面的分析中可知Nios II IDE把具有共性的部分放在底层HAL库中实现了，下面是Makefile中定义的一些宏变量：
PROJECT := hello_led_0
SYSTEM_NAME := hello_led_0_syslib_1
SYSTEM_DIR := D:/develop/low_cost/software/hello_led_0_syslib_1
SUBDIRS := . include ${patsubst %, %/subdir.mk, $(SUBDIRS)}
MAKEFILE_LIST += $(patsubst %, %/subdir.mk, $(SUBDIRS))
APP_MAKEFILE := C:/altera/kits/nios2/components/altera_hal/build/app.mk
include $(APP_MAKEFILE)
在上述变量中，PROJECT、SYSTEM_NAME 、SYSTEM_DIR等变量，将在包含进来的规则文件中被引用。APP_CONFIG := Debug和SYS_CONFIG := Debug定义的编译生成文件的目录，文件末尾通过include包含进两个文件，其中subdir.mk文件中定义了：
C_SRCS += ${addprefix ,hello_led.c }
CXX_SRCS += ${addprefix ,}
ASM_SRCS += ${addprefix ,}
很明显是用户项目的三种不同源文件。
   而include $(APP_MAKEFILE)则引进了系统编译规则，这些规则定义在底层HAL的build目录中。顺藤摸瓜，我们接着来分析app.mk文件。
在app.mk文件中主要完成两部分工作，前一部分我们可以通过变量的替换看出：包含引入了项目库目录中的generated_all.mk文件，该文件定义了以下变量：
COMPONENTS_PROCESSOR      = /cygdrive/c/altera/kits/nios2/components/altera_nios2
COMPONENTS_OS             = /cygdrive/c/altera/kits/nios2/components/altera_hal
COMPONENTS_DEVICE_DRIVERS = /cygdrive/c/altera/kits/nios2/components/altera_avalon_pio                             /cygdrive/c/altera/kits/nios2/components/altera_avalon_jtag_uart                             /cygdrive/c/altera/kits/nios2/components/altera_avalon_sysid                             /cygdrive/c/altera/kits/nios2/components/altera_avalon_cfi_flash                             /cygdrive/c/altera/kits/nios2/components/altera_avalon_uart
PTF = D:\develop\low_cost\low_cost_1C20.ptf
CPU = cpu
这些都是硬件相关的。
app.mk后半部分主要引入了项目相关外部设备组件的编译变量
COMPONENT_MAKEFILES = $(wildcard $(foreach component, $(COMPONENTS),                                  $(component)/HAL/src/component.mk))
其中include $(SOPC_KIT_NIOS2)/components/altera_hal/build/app_rules.mk包含引入了应用程序编译规则。
这些编译规则文件一般都在altera\kits\nios2\components\altera_hal\build目录中，通过前面我们提到的文件中逐步定义变量，到这些.mk文件中时都已经统一了，做到和具体项目无关。我们在分析的时候需要有耐心做一些变量的替换才能理解，对照我们在（一）部分介绍的GNU MAKE的知识去理解。
     以上的分析只是抛砖引玉，希望大家奉献在编译环境设置中更好、更有效的方法。



欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0