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

全文完。