当把一个项目从旧电脑上原封不动地复制到新电脑，或者把整个工作区从一块硬盘挪到另一块硬盘之后，不少人都会遇到一种情况：C/C++test这个工具里面，突然就冒出来一大片红色的错误提示。明明源文件都还在原来的位置，原来的工程也能正常编译通过，可工具那边却一直提示说头文件找不到了、编译时用的那些参数失效了，或者链接的目录丢失了。在大多数时候，这都不是代码本身出了什么毛病，而是因为旧的工作区配置里面保存了很多绝对路径，搬了家以后，那些路径还依然指着原来的老目录，完全没有跟着变过来。再加上C/C++test的项目文件里面，还有可能挂着外部链接的文件夹、构建过程产生的数据文件，以及一堆缓存信息，这里面只要有一项没有同步好，错误就会扎堆地跳出来。

　　一、工作区迁移后为什么会出现全红的情况

　　工作区里一下子变红的时候，更合适的办法是先去看看工程的配置哪里不对劲，而不是一条一条地去改源码里那些include语句，因为那样做很容易绕远路，大部分报错其实都能靠调整配置一次性解决掉。

　　1、旧绝对路径已经不起作用

　　在项目上面点右键，顺着【Parasoft】→【Properties】→【C++test】相关设置的路径进去，就能看到Build working directory、Build data file、Dependency files还有编译器路径这些选项，需要仔细检查一下它们是不是还指着以前的磁盘。比如项目原来放在D盘，现在整个搬到了E盘，要是这些配置项里还保留着D盘的路径，那工具就自然找不到对应的Makefile、BDF文件，还有那些头文件了。官方的帮助文档里面也提醒过，写死的绝对路径会让项目在迁移时变得很难处理，这种情况下更适合用项目变量来代表这些位置。

　　2、链接目录没有重新指向源码

　　有的工程会把源代码放在工作区的外面，然后通过一种叫做Linked Folder的方式把它挂接到项目里面来。这么搬完家以后，光看项目树的目录结构，会发现那些文件夹的名字都还在，好像没什么变化，可实际上它跟外面那个真实文件夹之间的链接已经断掉了，工具自然就读不到里面的内容。C/C++test的官方说明里也专门提到过，项目里面是可以放一些指向外部文件位置的链接目录的，对于这种项目，在设置相关路径的时候就应该用resource_loc这种变量，而不是直接写死一个绝对路径，否则环境一换就很容易失效。

　　3、构建数据里还记录着旧目录

　　假如项目是通过cpptestscan、cpptesttrace，或者是直接导入compile_commands.json这种方式创建出来的，那它会把当时真实构建过程中用到的源码路径、头文件目录，还有编译时加的那些参数，完整地记在对应的构建数据文件里面。当源代码的位置移动了之后，之前生成的那份BDF文件，或者那个编译数据库，很可能就不再适用了，因为里面记录的路径都还是旧的，这种情况就必须重新去生成一次。官方资料里面也说明了，对于命令行方式构建的项目，可以先借助cpptestscan这类工具去把构建信息重新抓一遍，然后再导入进来生成新的项目。

　　二、工作区路径失效了应该怎么修复

　　动手修复的时候，先把工程的物理位置处理好，然后再去更新构建数据文件和缓存，不能光把表面的报错标记给清掉就完事，否则下次再跑分析的时候，同样的错误照样会重新冒出来。

　　1、重新关联源码目录

　　打开项目的属性设置，找到那些外部链接的目录，先看看它们是不是已经断开了。如果是，就手动把它们重新指向当前源码真实的存放位置。如果是从头新建一个项目的话，也可以在创建的时候就把默认的那个位置选项给取消掉，直接把Location这一栏填上源码的根目录，这样项目本身就直接坐在源码上了；要是仍然想保留一个独立的工作区文件夹，那就还是用链接目录的方式去接入外面的源码，只不过一定要记得在迁移后做一次重新链接。

　　2、把绝对路径替换成变量

　　为了避免再次碰到这种路径失效的麻烦，比较好的习惯是用变量来代替那些写死的路径。一般的普通项目，可以优先使用${project_loc}这种变量；如果源码目录是通过链接方式加进来的，那就可以用${resource_loc:/项目名/目录名}这样的格式来指定。要是团队里不同人电脑上的源码根目录都不太一样，还可以用${env_var:变量名}去读取系统环境变量，这样每个人只需要在自己的电脑上设好这个环境变量，工程交过去以后就不用一条一条地去改本机的具体路径了。

　　3、重新生成构建数据

　　回到真实的构建环境里去，先做一次彻底的干净构建，在这个过程里重新把BDF文件或者compile_commands.json给生成出来。接着，把C/C++test项目设置里的Build data file路径更新成这个新生成的文件。等这些配置都改好以后，再去项目设置里面点一下【Reset cache】这个按钮，让工具忘掉以前缓存下来的那些旧信息，重新去读一遍现在的构建选项，这样才算真正更新到位。

　　4、重新执行一次完整分析

　　把之前残留的那些错误标记全部清掉，再完整地跑一次静态分析。跑完之后，重点去看一下头文件找不到的提示、编译器参数不认识的错误，还有那些因为宏定义没生效导致的异常，是不是都已经消失了。如果这个时候只剩下零零星星的几个报错，那就对着具体的文件一个一个去修正，不要再轻易去想整体重建整个工作区的事情，因为小范围的修正反而更能保持项目配置的稳定，不容易引出新的问题。

　　三、迁移后怎么避免再次出现全红的问题

　　每一次迁移后都这样折腾一遍也不是办法，因此把工作区配置成一种可以方便复用的形式，以后换电脑或者换目录的时候，就不用再从头来过了。

　　1、统一源码的根目录

　　团队内部可以先商量好，一起约定一个统一的环境变量名称，比如就叫PROJECT_ROOT，然后让项目里所有用到的路径配置，都去引用这个变量。这样一来，不同成员把代码拉到本地以后，只需要在自己的电脑上设置一次这个变量的值，指到自己的实际路径，其他地方就全都自动衔接上了，不用再到处去改配置。

　　2、不要直接复制缓存数据

　　工作区里面那些.metadata文件夹、.cpptest文件夹，还有过去留下来的增量分析数据，最好不要长期在不同电脑之间直接复制使用，因为这些东西往往也跟本机的路径和配置强绑定。如果是在命令行模式下运行，可以用-workspace这个参数来单独指定分析数据和增量数据存放的目录，而且还要注意，同一个工作区目录不适合同时被多个分析任务一起占用，不然数据很容易互相干扰。

　　3、覆盖率迁移要单独处理

　　另外还有一种情况，如果迁移之后还需要把以前积累的那些覆盖率数据导入进来接着用，那源码文件要么就继续放在原来的老位置不要动，要么就去设置一个叫CPPTEST_COVERAGE_SRC_ROOT的变量，用它来完成从旧路径到新路径的映射转换。要是这两样都没有做，那打开覆盖率报告的时候，就可能会出现一堆文件找不到的情况，数据显示不全。

　　总结

　　总体来看，C/C++test工作区在迁移之后之所以会出现大片的红色报错，以及当工作区路径失效以后应该怎么去修复它，排查的时候可以大致照着这个顺序来走：先检查是不是绝对路径在捣乱，再看链接目录有没有断开，然后重新去生成构建数据，顺便把旧的缓存清干净。在项目配置里面，尽量多用project_loc、resource_loc这类变量，或者通过环境变量来处理本机路径的差异，不要让具体的目录直接写死在配置里。迁移的整套操作做完以后，再从头跑一轮完整的分析，用它来确认头文件、宏定义，还有编译器的各种选项，都已经能够被正确地识别到，这样整个环境才算真正稳定下来。