Rebuild Current BSP and Subprojects并不像通常所理解的，会强制重新编译整个BSP以及所有子工程，实际上，它仅仅强制重新编译了BSP，而子工程是没有强制重新编译的，这里说的强制重新编译是指以"build -c"的方式重新编译所有代码。
一般情况下，如果仅仅修改了BSP的代码，只需要编译BSP目录即可，如果修改了子工程的代码，也只需要编译该工程。这都是提高编译速度的一些小技巧，尽量少用很费时间的Sysgen和Clean Sysgen。
如果改变了项目的环境变量，且该环境变量影响了BSP和子工程。譬如多个型号的产品共用一个解决方案、一份BSP和子工程，在发布版本时，通过修改产品类型的环境变量，然后Rebuild Current BSP and Subprojects。本以为理所当然的事，却可能碰到奇怪的问题。修改产品类型后，Rebuild Current BSP and Subprojects，有一个子工程编译不过，而再单独编译一次该工程，又正常。
跟踪了一下Rebuild Current BSP and Subprojects的过程，发现子工程的代码并没有重新编译（因为没有修改代码，仅仅是根据环境变量在sources文件中设置了不同的宏定义和链接所用的库），而在链接时根据产品类型的定义使用了不同的lib库，库和代码不匹配导致链接错误。
找到问题的原因，解决起来就简单了。修改产品类型后，首先Rebuild All Subprojects，然后再Rebuild BSP。或者写一个批处理，在编译之前先手动Clean一下BSP和Subprojects，然后再Rebuild Current BSP and Subprojects。或者还可以自定义一个菜单，执行Rebuild All Subprojects和Rebuild BSP的操作，实现一键快速编译。
最后简单说明下Rebuild Current BSP and Subprojects的流程，首先执行"Starting Build: blddemo -c -qbsp"强制重新编译BSP，然后执行"BLDDEMO: Building PostSysgen User Projects call %_PROJECTOAKROOT%\PBPostSysgenProjects.bat"。打开PBPostSysgenProjects.bat文件，内容如下：
setlocal pushd cd /d C:\WINCE600\platform\tws89x\filters\tcccamfilter build if exist build.log type build.log >> %_WINCEROOT%\build.log if exist build.wrn type build.wrn >> %_WINCEROOT%\build.wrn if exist build.err type build.err >> %_WINCEROOT%\build.err cd /d C:\WINCE600\platform\tws89x\filters\tccjpgencfilter build if exist build.log type build.log >> %_WINCEROOT%\build.log if exist build.wrn type build.wrn >> %_WINCEROOT%\build.wrn if exist build.err type build.err >> %_WINCEROOT%\build.err
Build All Subprojects和Rebuild All Subprojects则执行"Starting Build: call C:\Users\HJB\AppData\Local\Temp\PB\PBPostSysgenProjects.bat"，Rebuild All Subprojects对应的PBPostSysgenProjects.bat内容如下：
setlocal pushd set WINCEREL=1 cd /d C:\WINCE600\platform\tws89x\filters\tcccamfilter build -c cd /d C:\WINCE600\platform\tws89x\filters\tccjpgencfilter build -c
