Green Hills MULTI工程怎么配置，Green Hills MULTI工程依赖路径失效怎么排查，这在嵌入式工程迁移、更换电脑、更换工具链版本，或接入CI构建的时候经常能碰到。MULTI工程并不只是用来保存源文件的列表，它还会把编译器、目标处理器、include路径、库路径、链接脚本、启动文件以及构建选项全都关联在一起。路径一旦被写成了个人电脑上的绝对目录，或者项目结构调整后没有同步更新，就容易出现头文件找不到、库文件找不到、链接失败，或者工程能打开却无法编译这一类的问题。

　　一、Green Hills MULTI工程怎么配置

　　在配置MULTI工程的时候，先不用急着把所有源码都添加进去，比较稳妥的做法是先把目标平台和工具链确认下来，再去整理源码、头文件、库文件还有链接的配置，等工程能够被稳定构建起来以后，再回头调整调试器、下载方式以及运行参数。

　　1、先确认目标平台和工具链

　　工程被创建或者打开之后，需要先查看【Target】、【Processor】、【Toolchain】和【Build Configuration】这些基础的项目。

　　不同的芯片平台、不同版本的Green Hills编译器，对于默认选项、库文件以及启动代码的要求可能会不一样，比如说同一套源码，放在RH850、PowerPC、ARM这些平台下面，编译参数和链接文件通常都是不同的，基础平台一旦被选错，后面就算添加再多的路径，也只是在暂时绕开问题。

　　2、整理源文件和工程分组

　　源文件可以按照模块被加入到工程里面，用驱动层、服务层、应用层、配置文件这一类分组方式去整理，不要把所有的文件都平铺在一个列表当中，否则后面排查编译错误的时候会相当耗时。

　　如果工程原来是从其他构建系统拿过来的，比如Makefile、CMake或者AUTOSAR生成的工程，就需要留意MULTI工程里的文件列表是否完整，有些文件平时是靠脚本自动生成的，手动配置工程的时候就容易被漏掉，结果本地工程编译不通过，而原来的构建系统却可以正常通过。

　　3、配置头文件路径和宏定义

　　在工程选项当中需要检查【Include Directories】和【Preprocessor Defines】，把项目的头文件目录、平台头文件目录、生成代码的目录以及第三方组件的目录，全都加进去。

　　宏定义也需要和实际构建保持一致，嵌入式项目常常会利用宏来切换芯片型号、编译模式、功能开关以及内存段的配置，少掉一个宏，代码可能会走到完全不一样的分支里；头文件就算被找到了，编译出来的结果也和目标工程并不一致。

　　二、Green Hills MULTI工程依赖路径失效怎么排查

　　遇到依赖路径失效的时候，需要先看报错的具体类型。头文件找不到、库文件找不到、链接脚本找不到、启动文件找不到，这些情况背后对应的路径位置是不一样的，不要一看见路径错误就去到处修改，那样很容易把原本可以使用的配置也一并改坏。

　　1、先定位是哪一类路径失效

　　查看【Build Output】里面第一处有效的报错，确认到底是include路径、library路径、linker script路径，还是源码文件路径发生了失效。

　　如果是No such file or directory这类报错，就需要先看缺少的是.h、.a、.ld、.gpj，还是某一个生成文件，文件类型不同，排查的入口也会不一样。头文件的问题通常去查include目录；库文件的问题则去查library search path；链接文件的问题需要去查linker设置或者构建脚本。

　　2、检查绝对路径和相对路径

　　打开工程选项以后，要重点查看路径当中是否还留着个人用户名、旧盘符、旧工作区或者旧工具链目录。

　　不少工程在原电脑上可以编译，是因为路径被写成了D:workproject_oldinclude这样的绝对路径，换到新电脑上以后，目录已经不存在，依赖关系自然就失效了。团队工程更适合采用相对路径，或者统一使用环境变量，以避免每个人都去单独修改一份本地配置。

　　3、核对环境变量是否生效

　　假如工程路径里用到了变量，就需要去检查【Environment Variables】，或者查看启动MULTI时的命令行环境。

　　有些变量在Windows系统环境里面是存在的，可是通过快捷方式启动MULTI的时候却没有被加载；有些变量只在CI脚本里被定义过，本地打开工程就会失效。碰到这种情况，可以先在构建输出里面查看展开以后的真实路径，再判断变量究竟有没有被解析到。

　　三、MULTI工程路径问题怎么减少反复出现

　　路径问题如果只是靠临时改动本机来解决，很快就会在下一台电脑或者下一条流水线里面再次出现，工程配置最好从一开始就按照团队共享的方式去整理。

　　1、统一工程目录结构

　　把源码、配置文件、生成代码、第三方库以及链接脚本都放在稳定的目录下面，工程当中尽可能使用相对路径去引用。

　　目录结构不要频繁被改名，比如说config、generated、lib、linker这些目录，一旦被引入工程配置，后续迁移的时候就需要保持一致，确实要重构目录的话，也要同步更新工程文件和构建脚本。

　　2、把本地差异放到变量里面

　　工具链安装目录、SDK目录、芯片包目录这一类内容，在不同电脑上可能并不相同，可以用环境变量去承接，不要直接在工程里写死。

　　例如工具链路径由一个统一的变量来指向，工程则只去引用这个变量，这样更换电脑的时候只需要修改变量，不用在MULTI工程里面到处翻找路径，CI环境也更容易复用同一套工程配置。

　　3、保存可复现的构建说明

　　工程能够编译通过以后，需要把工具链版本、工程入口、必要的变量、依赖目录，还有常见的清理方式全部写清楚，不要只依赖某一个人的本机环境。

　　如果后面再出现“我这台能编译，你那台不能编译”的情况，就可以先按照说明去核对版本和路径，而不是直接去猜测，对于长期维护的嵌入式项目来说，这比单次把工程调通更加重要。

　　总结

　　Green Hills MULTI工程怎么配置，Green Hills MULTI工程依赖路径失效怎么排查，重点是把工程配置、工具链环境以及路径引用统一起来。配置工程的时候，先确认目标平台和工具链，再去整理源码、头文件路径、宏定义、库路径和链接文件；依赖路径失效的时候，先看报错的文件类型，再去检查绝对路径、相对路径、环境变量和构建输出。工程目录结构稳定、变量使用规范、构建说明完整，MULTI工程在迁移和多人协作时，才不容易反复出现路径方面的问题。