当项目环境发生变动，比如从一台电脑挪到另一台电脑，更换了工作区的路径，或者之前是跑在持续集成的环境里、现在需要迁回到本机进行调试和修改，这时候用户常常会撞上一种挺憋闷的状况：在开发工具的界面上可以看见工程名字，但点开逐级的源码目录却发现底下空了一大块，很多原本该在那里的源代码文件并没有跟着显现出来。本文打算围绕Parasoft C/C++test这个工具，重点聊聊C/C++test工程到底应该怎么完成导入操作，以及万一在导入以后碰到了源码丢失的表现，我们该从哪些方向把它找回来。在处理之前，心里头需要先装着一个基本的概念：C/C++test的工程文件，它本质上是用来存放项目结构、分析配置这一类信息的，并不负责把真实的源代码复制并保管到工作区里头，源码始终是留在原本的代码目录下面的。所以，导入工程这个操作，绝不等于是把源码搬了进来。

　　一、C/C++test工程怎么导入

　　C/C++test工程的导入方法，首先要看原来的项目究竟是哪一种类型。如果它本身就已经是一个现成的Eclipse工程，那么直接把它导入到当前的工作区就行；但如果碰上的是基于Makefile、CMake或者其他构建系统搭建的项目，更合适的路线则是想办法先生成一份构建数据文件，之后再拿这份数据文件去建立出C/C++test工程。

　　1、已有工程直接导入工作区

　　如果手头已经有了一个Eclipse工程，我们首先把C/C++test启动起来，然后顺着菜单栏依次点开【File】→【Import】→【General】→【Existing Projects into Workspace】。在弹出来的选择界面里，去找到原工程所在的根目录，等工具识别出要导入的项目列表后，核对一下有没有缺漏，最后按下【Finish】就可以了。不过要特别留心一种情况：有些工程在内部使用了链接目录，也就是说它里面显示出来的文件夹并不是真正的物理拷贝，而是指向了工程外部的某个路径。在导入这类工程的时候，千万不能随手把“复制到工作区”那一个复选框给勾上，不然原先生效的相对路径关系就有可能出现错乱，导致后面找不到文件。

　　2、通过构建数据文件创建工程

　　拿到构建数据文件之后，我们接着执行【File】→【New】→【Project】这一组菜单操作，在列出的项目类型里找到C/C++test分类底下专门用来导入它的那个入口。点进去以后，按照提示把刚才生成的构建数据文件所处的具体路径填上去，给新的工程起个名字，再指定好希望把它放在哪个目标位置。等导入过程全部跑完，立马要跟进做一件事：进入工程的属性设置页面，仔细去核对一下编译器有没有选对、包含目录是不是都指向了正确的地方、宏定义的设置跟原来编译的时候是不是一样，还有工作目录是不是设得靠谱。在比较新的Parasoft文档里面，还特意强调了，导入之后最好再到【Properties】→【Parasoft】→【C/C++test】→【Build Settings】这个节点下面，把整个配置重新确认一遍，这样能少走很多弯路。

　　二、C/C++test工程导入后源码丢失怎么找回

　　导入工程以后，一眼看去发现源码目录里面空空的，这种事情背后通常藏着两种可能：一种可能是代码文件实实在在地还呆在磁盘上面，只是工程跟它之间的链接断掉了，所以界面上并没有把它显示出来；另一种可能则是源码目录本身真的被挪走了，被删掉了，或者压根儿就没从版本管理库里拉取到本地来。这个时候，处理起来一定要克制住自己马上重建一个工程的冲动，头一步应该是顺着路径去找原因，而不是推倒重来。

　　1、先刷新工程目录

　　我们在Project Explorer面板里面找到那个出问题的工程，对它点右键，先执行一下【Refresh】，也就是刷新操作。如果源代码是刚刚才从别的地方拿过来、复制到这台电脑上的，那么刷一下之后通常就能让文件重新在这些列表里显示出来。要是刷新以后还是瞅不见那些失踪的文件，那就继续在工程上右键单击，依次点开【Properties】→【Resource】，去瞅一眼这个项目实际映像到的是磁盘上的哪个目录，查一查它是不是对准了真实存放源码的那个文件夹。

　　2、检查链接目录和路径变量

　　还有一类情况是发生在那些带有链接文件夹的工程身上，这类文件夹看起来就像是工程目录下的一个普通子目录，可实际上它指向的来源位于工程外部的某个地方。一旦搬到另一台电脑上，原来的盘符习惯、用户的文件夹名称，甚至目录的层级结构都可能变得不一样了，那么这条链接自然就会断开，再也找不到它当初指着的那块地方。正因为容易发生这种失效，Parasoft的文件资料里专门列出来了一组路径的引用方式，比如project_loc、workspace_loc、resource_loc，还有通过操作系统的环境变量去表述路径，用上这些相对灵活的写法之后，就能尽量避开硬写绝对路径带来的麻烦，让工程在不同电脑之间穿梭的时候稍微省心一些。

　　3、源码真正删除时从版本库恢复

　　还有最后一种也是最让人头疼的情况，那就是本地的源文件真的被删掉了，这种时候我们得明白一件事情：C/C++test工程它本身并不能被当成一个源代码备份来使用。一旦确认文件确实找不回来了，我们就只能老老实实从Git、SVN这样的版本管理系统，或者日常备份里把这些消失的源代码给恢复回来，等文件全部落回原来的路径之后，再回到工程里面去执行一次刷新。假设手头仅剩下一些工程配置、一份构建数据文件，或者残缺的工作区配置，而没有真实的源码内容，那无论怎么使劲，也是不可能把整套代码凭空变回来的。

　　三、C/C++test工程导入后怎么复核

　　等到工程重新恢复到了正常状态，先别急着上来就对着整个工程跑全量分析，这样做动静太大，而且容易因为初期配置不对产生一大堆无意义的告警。更稳当的路子，是先花一点时间把源码是否齐全、构建配置是不是正确，还有将来生成报告用的路径是不是都设得恰当，这三样东西逐一确认一遍。

　　1、抽查核心目录

　　首先，手动去抽查几个核心的目录，看看主要的功能模块、存放头文件的地方、项目倚赖的那些第三方库，还有自动生成出来的代码目录，它们下面的文件是不是都齐整了。有的时候源码的目录结构看起来好像该有的都有，但这并不代表包含目录那边的设置就一定没有遗漏或偏差，所以这一步不能光用眼看，要配合工程设置去交叉检查一下。

　　2、执行一次小范围分析

　　接着，挑一个范围比较小的模块，单独跑一次静态分析，看一看分析结果里面有没有冒出大批量的“头文件找不到”的警告，或者是宏没有定义的提示，再或者是编译器类型跟实际使用的对不上的报错。如果发现这类问题密密麻麻的，那就优先返回到Build Settings配置界面里，把涉及到的编译器选项、包含路径和宏定义重新校准一下。

　　3、保留可迁移配置

　　等到整个工程运转得比较稳定了，最后一步是把它变成一套可以携带着走的配置。把当时生成构建数据文件所用的方法、完整的构建命令、用到了哪些路径变量，还有对应的版本库地址，这一整套东西都记录下来，好好地保存好。这样一来，后面如果再碰见要换个电脑工作，或者是把工程接入到Jenkins这种持续集成平台上的时候，再想重新生成工程就会顺手很多，不至于又把同样的问题重新排查一遍。

　　总结

　　把上面的内容归结起来，对于C/C++test工程的导入，核心就在于区分好原来的项目类型：已经有了Eclipse工程的就直接导入工作区，而基于其它构建系统的项目，则要先利用cpptestscan或cpptesttrace生成构建数据文件，然后再借它来创建出新的工程。万一在导入以后瞧见了源码丢失的现象，也不要慌乱，先试着刷新一下工程目录，再去检查那些链接目录和路径变量有没有失效；如果发现是构建数据文件里面包含的源码清单不全，那就要回头去做一次彻底的完整构建并重新生成BDF。