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 已經被修改。

在上面我們了解了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 "Properties" 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的知識去理解。
以上的分析只是拋磚引玉，希望大家奉獻在編譯環境設置中更好、更有效的方法。