<有一定的了解，则会对快速解决这些问题大有帮助。
## 示例
让我们来看一个分步示例，了解如何使用向导导入一个示例 CCSv3.3 工程，以及如何通过后期必要的手动调整解决迁移过程中产生的问题。
首先，选择 *Project → Import Legacy CCSv3.3 Project* 来启动向导。
**选择Legacy CCS Project**：在出现的向导对话框中，指定要导入的 CCSv3 pjt 文件。可以使用 **Browse...** 按钮和 **Select project** 选项来明确指定一个工程，也可以使用 **Select search-directory** 选项来选择一个文件夹，以便在其中递归搜索要导入的 CCSv3 工程。如果使用第二种方法，任何符合条件并能够导入的工程都将显示在 **Discovered legacy projects** 列表中。选择一个或多个工程后，每个项目都可以选择 **Copy projects into workspace**（将工程和相关文件导入 CCS Eclipse 工作区）或 **Keep original location**（将工程导入到原始 pjt 文件所在的目录）。由用户决定哪个选项最好。如果是第一次尝试导入，第二种方法可能更适合。这是因为许多 CCS 3.3 pjt 工程都位于现有目录结构中的某个位置。将其移出此目录结构可能导致更多的各种搜索路径的问题。如果确定选择第二种方法，建议选择 **Create a subfolder for each Eclipse project (recommended)** 选项。这是为了将新生成的 CCS Eclipse 工程与目录中现有的旧文件完全隔开。
在下面的示例中将明确选择 **gsmhrc64_enc.pjt** 示例工程，并且将在原始位置的子文件夹中创建 CCS Eclipse 工程文件：
**选择Compiler**：下一步是指定要使用的编译器版本。默认选择的版本将是 CCS Eclipse 程序当前发现的最匹配版本。在列表中的工程上选择并点击 **Edit...** 按钮将启动另一个对话框，可以让 CCS Eclipse 发现另一个编译器版本。以下示例中使用了默认版本：
[[y 要使用哪个编译器版本？
原始 *.pjt 使用的编译器版本可能早于 CCS Eclipse 最初提供的版本。由用户确定此较新版本的编译器是否会与导入的工程兼容。较新版本的编译器可能包含有价值的错误修复和性能改进。
]]
**Enable DSP/BIOS Tools Support**：默认情况下，向导将在下一步扫描工程以确定 pjt 是否为 DSP/BIOS 工程。如果是，那么将在 CCS Eclipse 中为该工程启用 DSP/BIOS 支持。这里还有一个选项，无论原始 pjt 文件是否使用了 DSP/BIOS，都可以为所有工程启用 DSP/BIOS 支持。默认选项通常是此处的推荐选项。
[[y CCS 的当前版本不带有 DSP/BIOS！
可从在[应用中心](./ccs_app_center.html)访问它。
]]
**Set Advanced Options**：下一步将允许通过选项指定自定义的公共根目录 (**Common root**) [工程变量](./ccs_portable-projects.html#variables)。如果此处未指定，则将创建并使用默认的公共根目录。
完成向导的所有步骤后，按 **Finish** 按钮将完成导入，并且新生成的 CCS Eclipse 工程将出现在 **Project Explorer** 视图中。遇到的任何迁移问题都将记录在工程位置中一个名为 **migration.log** 的文件内。
建议打开此日志文件检查是否存在任何问题。对于下面的示例，我们可以看到两个潜在的问题：
第一个问题是：
<pre>
!WARNING: Source file 'rts64pluse.lib' has been linked into the project relative to variable 'CG_TOOL_ROOT'. It is recommended, however, that you avoid linking resources from the build-tool directory - consider using build-options to reference include-files and libraries.
</pre>
这实际上是合理的建议。应该在链接器选项中引用库，而不是将库显式添加到工程中。这一规则不仅适用于 **rts64pluse.lib**，还适用于示例工程中的另一个库 - **gsmhrenc_tii.l64Pe**。
解决方案是从 **Project Explorer** 视图中删除指向它们的链接，即选择并删除它们（*右键点击 → Delete*）。然后打开工程属性 (*Project → Properties*)，转到 **File Search Path** 链接器选项，在 **–-library** 字段中添加库。
请注意，对于 **rts64pluse.lib**，不需要它的完整路径。这是因为库的位置已经在下面的 **-–search_path** 字段中 (**{$CG_TOOL_ROOT}/lib**)。
日志中的第二个问题与较新编译器版本中的一个弃用选项有关。根据选项，可能需要解决或忽略它。在此示例中，可以忽略它。
下一步是编译工程。可能仍然存在一些未解决的问题。但是，最好先尝试编译工程以便暴露这些问题。
对于此示例，编译会立即失败，并显示以下错误：
<pre>
Buildfile generation error occurred..
Product XDAIS v1.0.0 is not currently installed and no compatible version is available.Please install this product or a compatible version.
Build stopped..
</pre>
原始 pjt 引用了当前 CCS 版本中不支持的旧 XDAIS 版本。可从工程中删除此不受支持的产品：
应用更改并重新编译工程后，XDAIS 错误将消失。但是，由于无法找到 **xdas.h** 和 **std.h** 头文件，两个新错误将出现：
<pre>
fatal error #5: could not open source file "xdas.h"
</pre>
<pre>
fatal error #5: could not open source file "std.h"
</pre>
**xdas.h** 是 XDAIS 包的一部分，但 CCS Eclipse 不随附此包。一个选择是使用 CCSv3 中的相应包，位于 <tt>[CCS3 安装目录]\C6000\xdais\include</tt>
std.h 可在 DSP/BIOS 包中找到。同样，一个选择是使用 CCSv3 中的相应包，位于 <tt>[CCS3 安装目录]\bios_[版本]\packages\ti\bios\include</tt>
下面的示例将两个路径都添加到工程的 **Include Options** 中的 **-–include_path** 字段。
应用更改并编译工程后，错误将消失。但是，链接器警告 #16002-D 将反复出现。类似于以下行的内容：
<pre>
warning #16002-D: build attribute vendor section TI missing in "C:/Temp/ccs3pjtimport/C64x+/GSMHR_1x/GSMHR_1x_ROOTDIR/gsm_hr/c64x/make/gsmhrenc_tii.l64Pe<GSMHR_TII_fnBest_CG_2.ol>": compatibility cannot be determined
</pre>
请注意，编译会成功通过，因为以上内容仅是警告而非错误。问题在于是否可以忽略该警告。[此处](./c2000_c28x-compiler-error-and-warning-messages.html#warning-build-attribute-vendor-section-ti-missing-in-library-or-object-compatibility-cannot-be-determined)提供了该特定警告的说明。由用户决定如何处理该警告。
编译成功后，该工程看起来已成功迁移并导入到 CCS Eclipse 中。仍然可以通过一些措施改进该工程（例如去除工程属性中的绝对路径、修复其他断开的链接和编译变量等），但至少完成了初始的“第一次通过”。
## 总结
如上面的示例所示，旧版导入向导还远远不够完善。在某些情况下，从头开始创建新的 CCS Eclipse 工程实际上更简单，而不必手动清除尝试由导入向导迁移的结果。无论是哪种情况，*强烈建议进行迁移的人员既要精通原始工程，又要对 CCSv3.3 和新的 CCS Eclipse 环境有良好的了解*。具有所有这些专业知识的人员将能够以最少的麻烦/工作量来确保成功完成工程的迁移。
<!-- End of markdown source -->
<div id="footer"></div>
]]>