Abstract
若我們從網路上下載範例程式，或者從書上的光碟將範例程式複製到硬碟時，只要是Quartus II版本正確，都可以正常地開啟Quartus II project並且編譯之，但Nios II project卻常常雖然能開啟，卻無法正常編譯，本文討論其root cause並提出解決方式。

Introduction
使用環境：Windows XP SP3 + VirtualBox 4.1.2 + Quartus II 11.0

本文將討論以下主題：

1.為什麼會需要改變目錄名稱或目錄位置?

2.改變目錄名稱或目錄位置，在Nios II project會遇到什麼問題?

3.Root cause與解決方法。

4.使用Blank Project方法所面臨的問題。

1.為什麼會需要改變目錄名稱或目錄位置?

我們常會有各種理由會改變原來project的目錄名稱或目錄位置：

1.為了管理方便，可能將原來在d:\project\的所有project移到e:\project\下

2.同事將project整個目錄壓縮給我，因為我並不知道該project放在同事電腦什麼工作目錄下，所以我將壓縮檔解壓縮到我自己的工作目錄下

3.從網路上下載整包範例程式的壓縮檔後，因為我並不知道原本範例程式所存放的目錄，所以我將壓縮檔解壓縮到我自己的工作目錄下

4.從書上光碟複製範例程式到硬碟，因為我並不知道原本範例程式所存放的目錄，所以我將範例程式複製到我自己的工作目錄下

5.新的project與舊的project類似，想從舊的project去做修改即可，開了一個新的目錄，將舊的project所有檔案複製到新的目錄下

6.為了管理方便，想改變原本project的目錄名稱

以上的情形，若是純粹Quartus II project，只要Quartus II版本正確，開啟*.qpf檔即可順利開啟，並且正常編譯，唯一有問題的是Programmer的*.cdf檔可能因為路徑不對無法寫入，只是重新指定*.sof與*.pof的位置即可。

Quartus II的*.qpf project概念類似Visual C++ 6的*.dsw或者Visual Studio的*.sln，整個project內的檔案是相對路徑，所以改變專案名稱或者改變目錄位置都沒有關係，只要檔案相對位置沒有改變，整個project就可以正常運作。

但是Nios II project就沒這麼單純了!!

Nios II SBT是用Eclipse去改的，用的是Eclipse的workspace概念，很類似Visual Studio的*.sln概念，但又不完全一樣。Eclipse允許你在一個workspace下，去管理多個project，workspace記住的是project的絕對路徑，所以當你Nios II project目錄名稱改變，或者目錄位置改變，該workspace自然就找不到了。

依照Eclipse workspace哲學的正規解法，此時你應該將目錄改變的Nios II project重新Import到你的workspace下。但事實上真的如此嗎?

2.改變目錄名稱或目錄位置，在Nios II project會遇到什麼問題?

我們實際做個實驗，如下圖所示，原本DE2_70_SOPC_golden_mini是一個在Quartus II與Nios II SBT都完全正常的project。

我們現在將目錄名稱改變，從DE2_70_SOPC_golden_mini改成DE2_70_SOPC_golden_mini2

大家都知到改變目錄名稱或目錄位置不會影響Quartus II project的開啟與編譯，所以就略過不討論，現在將焦點放在Nois II project部分。

開啟Nios II SBT，將workspace目錄切換到新的目錄DE2_70_SOPC_golden_mini2

開啟後顯示更改目錄名稱之前的2個project：hello_world與hello_world_bsp，由於現在目錄名稱已經改變，所以只能看到project名稱，卻完全無法開啟。

由於2個project已經無法開啟，我們將這2個project從workspace中刪除之。

刪除完後，整個workspace完全沒有任何project。

根據Eclipse哲學的正規解法：因為目錄已經改變，我們必須將2個project使用import的方式載入到新的workspace。

由於之前是使用Nios II SBT產生makefile的project，所以在此選擇Import Nios II Software Build Tools Project。

首先將hello_world project import進來，值得注意的是：要將Clean project when importing打勾，也就是在import project完時，馬上執行make clean，將之前所留下的object file全部清除。

import完成後，顯示了以下的warning，告訴我們project想include舊的專案路徑的目錄，但因為目錄名稱改變，所以include失敗。這是第1個問題。

接下繼續import hello_world_bsp，也記得將Clean project when importing打勾。

import完成後，並沒有顯示任何錯誤訊息與warning。

若在hello_world_bsp執行Nios II –> Generate BSP，會出現以下錯誤訊息，表示找不到*.sopcinfo。這是第2個問題。

若在hello_world_bsp執行Nios II –> BSP Editor會出現以下錯誤訊息，表示找不到*.sopcinfo。這是第3個問題。

若實際Build App project(hello_world)與BSP project，雖然仍可出現*.elf與*.a，但會出現以下錯誤訊息，表示Makefile找不到*.sopcinfo。這是第4個問題。

總結以上實驗，我們發現若改變目錄名稱或者目錄位置，在Nios II project會出現以下4個問題：

1.App project(hello_world)會出現include path not found warning。
2.BSP project(hello_world_bsp)會無法執行Generate BSP。
3.BSP project(hello_world_bsp)會無法執行BSP Editor。
4.Build App project(hello_world)與BSP project(hello_world_bsp)會出現Makefile找不到SOPC File的warning。

3.Root cause與解決方法。 

App project (hello_world) ：include path not found warning的Root cause

在hello_world的Properties的C/C++ General –> Paths and Symbols的GNC C與GNC C++，我們可以發現Include directories的目錄錯了，抓的都是修改前的目錄名稱，且這些目錄名稱還無法刪除或者修改，因為這是Eclipse自動抓的，這是第1個問題的root cause。

App project (hello_world) ：include path not found warning的Solution

Step 1：App project (hello_world)的properties

Step 2：C/C++ Build –> Discovery Options的Cygwin C Compier，按下Clear清除目前所抓的include path。

提示include path即將清除，將在Build時重新抓取include path，按『OK』繼續。

Step 4：C/C++ Build –> Discovery Options的Cygwin C++ Compier，按下Clear清除目前所抓的include path。

提示include path即將清除，將在Build時重新抓取include path，按『OK』繼續。

Step 5：檢查目前App project (hello_world)的include path

C/C++ General –> Paths and Symbols的Includes的GNC C，確定已經清除所有的include paths

C/C++ General –> Paths and Symbols的Includes的GNC C++，確定已經清除所有的include paths

原本App project (hello_world)的warnings也都不見了。

看到這裡，或許你會說：『不是應該要include新目錄的BSP project路徑才對嗎?』沒錯，如同Step 3與Step 4的提示所言，最後只要重新Build App project (hello_world)，就會重新discover include path，這我們等BSP project也解決後再一起重新Build。

BSP project (hello_world_bsp)無法Generate BSP的Root cause

首先了解Nios II SBT的Generate BSP到底做了什麼事情，根據[3] Nios II Software Build Tools Reference的p.15-8的nios2-bsp-generate-files與[4] Nios II Software Build Tools的p.4-30的Regenerating Your BSP所述，Generate BSP會根據BSP project的settings.bsp去尋找*.sopcinfo，再根據目前的*.sopcinfo去產生最新的drivers與HAL目錄所需要的檔案以及重新產生Makefile。

打開settings.bsp，會發現BspGeneratedLocation與SopcDesignFile所記錄的路徑都是改變目錄名稱之前的路徑，因此在Generate BSP時會找不到*.sopcinfo而導致執行錯誤。這是第2個問題的root cause。

BSP project (hello_world_bsp)無法Generate BSP的Solution

Step 1：修改BspGeneratedLocation與SopcDesignFile的路徑

修改完存檔時會出現以下錯誤訊息，主要是BspGeneratedTimStamp使用了中文時間，按下『Save as UTF-8』格式存檔即可。

Step 2：重新Generate BSP

可順利執行Generate BSP沒有任何錯誤訊息。

BSP project (hello_world_bsp)無法執行BSP Editor的Root cause

BSP Editor主要的目的在於修改settings.bsp一些只與BSP project相關的設定，BSP Editor無法執行，主要原因也是因為找不到*.sopcinfo。這是第3個問題的root cause。

BSP project (hello_world_bsp)無法執行BSP Editor的Solution

在之前的步驟已經修改過settings.bsp的*.sopcinfo路徑，所以也一併解決了這個問題，不必再做其他修改。

重新執行BSP Editor，可正常執行沒有任何錯誤訊息。

Build App project (hello_world)與BSP project (hello_world_bsp)會出現Makefile找不到SOPC File的warning的Root cause

App project (hello_world)與BSP project (hello_world_bsp)在Build時，事實上就是執行Make動作，所以需要參考Makefile，會出現warning主要是因為Makefile找不到*.sopcinfo。這是第4個問題的root cause。

Build App project (hello_world)與BSP project (hello_world_bsp)會出現Makefile找不到SOPC File的warning的Solution

理論上應該要去修改Makefile，不過由於執行Generate BSP時，nios2-bsp-generate-files已經根據修改過的settings.bsp更新過Makefile，所以我們不須再手動修改Makefile了。

重新Build BSP project (hello_world_bsp)，可順利Build沒有任何錯誤訊息。

最後重新Build App project (hello_world)，也可順利Build沒有任何錯誤訊息。

還記得在App project (hello_world) ：include path not found warning的Solution時，我們只清除了App project所include的錯誤路徑，但卻還沒有將正確地修正include路徑。

在Build完後App project (hello_world)後，馬上觀察hello_world的Properties的C/C++ General –> Paths and Symbols的GNC C與GNC C++，會發現正確的include路徑都回來了。

之前的洋洋灑灑，只是因為要邊解釋root cause邊介紹solution，其實整個步驟很簡單，只要5個步驟即可。

4.使用Blank Project方法所面臨的問題 

Nios II project只要改變路徑就無法編譯的問題，其實從我使用Quartus II 6.0時就已經發現了，應該說Nios II要使用Eclipse，就注定會有這個workspace的問題，很多人的解法(包括我自己)都與[2] 张亚峰的[笔记].为何在Nios II SBTE中，直接拖放到工程文件夹的文件，编译会出错？一樣，都是重新開1個blank project，然後重新將所需要的*.c, *.cpp拖放進新建的blank project，最後在手動去修改Makefile，這樣的解法的確是可以避開include paths錯誤與*.sopcinfo路徑錯誤的問題，不過settings.bsp與Makefile都是新的，所以必須手動去檢查Makefile是否與原project一樣，然後手動修改Makefile。

在[1] Getting Started with the Graphical User Interface的p.2-11的User Source Management有以下一段文字：

簡單的說，就是既然你用了Nios II SBT，就不建議手動去改Makefile，應該採用GUI或者Command line script的方式，由tools去更改你的Makefile，而不該手動去更改你的Makefile。本文採用的方式，雖然知道Makefile有問題，但依照Nios II SBT的邏輯，使用了Nios II SBT的GUI方式與流程去修改Makefile，完全沒有手動去修改Makefile，這樣可確定Makefile的正確性，也省去了一一比對原本Makefile的功夫。

完整程式碼下載
DE2_70_SOPC_golden_mini2.7z

Conclusion
這篇博文中的解法，是參考了Altera的官方資料所做出的總結，並經過無數次的實驗所歸納的心得， 因為這是我困擾好幾年的問題，假如你也為Nios II project路徑問題而困擾，可以參考本文的解法。

See Also
(原創) Qsys或RTL做修改後，Nios II SBT該如何面對新的硬體? (SOC) (Nios II) (Qsys)

Reference
[1] Getting Started with the Graphical User Interface
[2] 张亚峰的[笔记].为何在Nios II SBTE中，直接拖放到工程文件夹的文件，编译会出错？
[3] Nios II Software Build Tools Reference
[4] Nios II Software Build Tools

全文完。