在对嵌入式开发环境进行迁移的时候，“TASKING工程配置怎么导入、TASKING工程配置迁移后路径失效怎么办”这类问题经常会被开发者遇到；表面上看这只是一个简单的导入动作，但其实这个问题在背后牵涉到了工作空间、工程属性、编译器路径、头文件路径、库文件路径和调试配置等多个方面；因为TASKING的IDE是基于Eclipse工作方式的，所以操作者需要把工程导入和配置导入分开来处理，大家不能只把工程文件夹复制过去就觉得完事了。

　　一、TASKING工程配置怎么导入

　　在导入TASKING工程配置之前，操作者首先需要确认自己要导入的东西到底是“整个工程”，还是仅仅导入“工程属性配置”；因为这两种操作是不一样的，如果操作者把这两者弄混了，后面很容易就会出现虽然在软件里能看到工程、但是编译参数却不对的情况。

　　1、导入已有工程

　　通常情况下，操作者可以在TASKING IDE中点击【File】→【Import】来打开导入窗口。

如果面对的是已经存在的Eclipse工程，操作者可以选择【General】→【Existing Projects into Workspace】，接着在【Select root directory】里面把工程所在的目录选中。

在工程被导入进去之后，Project Explorer或者C/C++Projects视图里面就会显示出这个工程；需要注意的是，已有的工程在默认状态下通常只是被工作空间引用了，它们不一定会被复制到workspace文件夹里面，这一点操作者需要提前确认好。

　　2、导入TASKING工程属性

　　如果大家只是想把编译选项、链接选项、目标芯片配置这些工程属性挪过去，那么可以使用TASKING自带的工程属性导入导出功能。

具体的常见操作路径是先点击【File】→【Export】→【TASKING C/C++】→【TASKING C/C++Project Properties】，把.prop格式的文件从原来的工程里面导出来。

然后在新工程里面，操作者再次通过【File】→【Import】→【TASKING C/C++】→【TASKING C/C++Project Properties】把这个文件导进去；需要多加注意的是，在导入完成之后，目标工程里面对应的配置就会被这个.prop文件里的新配置给替换掉。

　　3、确认目标配置是否一致

　　当操作者在导入配置的时候，不能只盯着工程的名字看，还要看Debug、Release或者自定义配置是不是互相对应的；要是原工程导出来的是Debug配置，而新工程却被导入到了Release配置里面，那么后面算出来的编译结果可能就会不一样。

在导入工作全部做完之后，建议操作者打开【Project】→【Properties】，把里面的C/C++Build、Tool Settings、Include Paths、Libraries、Linker Script等内容一条一条地看一遍。

　　二、TASKING工程配置迁移后路径失效怎么办

　　在TASKING工程被迁移之后，路径失效的问题经常会发生，这通常不是因为软件本身坏掉了，而是因为旧电脑、旧目录或者旧工具链的绝对路径被保存在了原工程里面；当操作者更换了电脑、更换了盘符或者更换了workspace之后，这些老路径自然就没办法被系统找到了。

　　1、检查头文件和源文件路径

　　操作者应该先去查看报错的信息，要是系统提示了include file not found、cannot open source file或者No such file or directory这些字眼，一般情况下要优先去检查头文件的路径。

操作者可以进入【Project】→【Properties】→【C/C++Build】相关的配置页面，去看看Include目录是不是还指着原来的盘符或者用户目录。

　　2、检查库文件和链接脚本路径

　　要是工程在编译阶段是正常的，但是到了链接阶段却报了错，这时候操作者就要把重点放在Libraries、Library search path和Linker Script这些地方了；在TASKING工程里面，像.lsl链接文件、启动文件以及和芯片相关的库文件都是很常见的，它们的路径一旦失效了，就会导致链接失败、段地址出现异常或者找不到库文件；在处理这个问题的时候，操作者不要急急忙忙地去修改代码，而是应该先把工程属性里面的库路径和脚本路径拿出来挨个核对一遍。

　　3、检查Linked Resources和路径变量

　　要是工程里面用到了外部的源码目录，在迁移结束之后，操作者还要去检查Eclipse自带的Linked Resources。

操作者可以在【Window】→【Preferences】→【General】→【Workspace】→【Linked Resources】这个地方查看路径变量；当路径变量发生改变以后，操作者还需要对工程进行刷新，这样文件系统的变化才能被重新识别到。

　　三、TASKING工程迁移后怎么整理更稳妥

　　虽然工程能编译通过了，但这并不意味着迁移工作就已经做干净了；如果想要实现真正稳定的迁移，操作者就需要把路径、配置、依赖还有版本都梳理明白，这样才能避免下一次换电脑的时候再遇到一模一样的问题。

　　1、尽量减少绝对路径

　　工程里面包含的源码、头文件、库文件以及链接脚本，只要是能放到工程目录或者统一依赖目录底下的，操作者就尽量不要让它们零散地堆在个人桌面、下载文件夹或者某个临时的目录里面；相对路径这种方式更适合多个人一起合作，也更方便用来做版本管理；对于那些必须从外部引入的SDK、MCAL、iLLD或者板级支持包，操作者可以统一用环境变量或者路径变量来管理它们。

　　2、迁移后先Clean再Build

　　当操作者把路径修改好之后，不建议马上进行增量编译；操作者可以先点击执行【Project】→【Clean】，把以前留下的中间文件都删掉，然后再重新进行Build；因为旧的对象文件可能还是根据原来的路径、原先的宏定义或者原先的链接参数做出来的，要是直接继续编译的话，很容易会让问题看起来一会儿好一会儿坏。

　　3、建立迁移检查清单

　　建议操作者把工程迁移的检查项目做成一个固定的清单，这里面应该包括TASKING的版本、license的状态、workspace的路径、工程自身的属性、编译的配置、include路径、library路径、linker script、debug configuration、芯片的型号以及启动文件；特别是在团队项目里面，大家不要只把工程的压缩包交过去，最好能把工具链的版本和依赖目录的结构也同步写清楚。

　　总结

　　针对“TASKING工程配置怎么导入，TASKING工程配置迁移后路径失效怎么办”这两个问题，解决的核心并不是简单地去复制工程，而是要把“工程导入”和“配置导入”这两种行为区分开来；当工程被导入进来之后，操作者要重点去核对工程属性、编译配置、头文件路径、库路径、链接脚本还有Linked Resources；在迁移之后如果碰到了路径失效的情况，操作者可以先从绝对路径、路径变量和外部依赖目录开始查起，然后再去执行Clean和完整的Build；通过这样的步骤处理下来，工程迁移的过程会变得更稳，也能让后续多人协作时反复报错的情况变少。