1. 多lib项目里Verilog重名到底有多要命
做数字IC前端验证的人，迟早会撞上多lib联合编译这堵墙。项目小的时候，一个lib走天下，vcs -f filelist.f一把梭，什么问题都没有。可一旦项目规模上来，比如SoC里集成了CPU子系统、DSP子系统、外设子系统，每个子系统由不同团队维护，各自有独立的lib目录、独立的filelist、甚至独立的编译选项，这时候如果你还想着把所有文件塞进一个filelist里一把编译，大概率会遇到两类问题：一是模块名冲突，二是编译时间爆炸。
模块名冲突这件事，说起来简单，实际排查起来非常折磨人。Verilog本身没有命名空间的概念，所有module共享一个全局符号表。两个不同lib里各有一个叫fifo_ctrl的模块，功能完全不一样，一个深度16，一个深度64，VCS在elaboration阶段会直接报重复定义，或者更阴险的情况——它不报错，而是默默用了其中一个，导致仿真行为诡异，波形对不上，你查了三天才发现是模块被覆盖了。这种问题在项目后期暴露出来，代价极大。
分开编译（separate compilation）就是解决这个问题的核心手段。VCS支持把不同lib分别编译成独立的库文件，然后在top层做链接。这样每个lib内部的模块名互不干扰，lib之间通过明确的接口信号通信。听起来很美好，但实际操作中有一堆细节：lib的划分粒度怎么定、重命名怎么做才不会破坏层次、编译顺序怎么控制、增量编译怎么配、脚本怎么组织才能让团队里每个人都能一键跑通。
这篇内容就是把我自己在多个多lib项目里踩过的坑、总结出来的脚本框架、以及那些文档里不会写的经验，完整地摊开讲一遍。不管你是刚接触VCS多lib编译的新手，还是已经用过但总觉得脚本不够顺手的熟手，应该都能从里面找到能直接用的东西。关键词里提到的VCS、Verilog、lib、编译、脚本，这几个点我会逐一展开，重点放在“怎么落地”上，而不是泛泛地讲概念。
2. 先搞清楚VCS分开编译的底层逻辑再动手
2.1 为什么不能简单粗暴地合并filelist
很多人第一反应是：既然模块名冲突，那我加前缀不就行了？把所有模块都改成libA_fifo_ctrl、libB_fifo_ctrl，问题不就解决了？这个思路在理论上可行，但实际项目里几乎没人这么干，原因有三。
第一，改动量太大。一个中等规模的lib可能有几百个模块，手动改前缀不现实，用脚本批量改又会引入新问题——比如跨模块例化时的名字也要同步改，`define宏里的名字也要改，甚至testbench里的层次路径引用也要改。牵一发动全身，风险极高。
第二，破坏了代码的可读性和可维护性。模块名带上一长串前缀之后，代码看起来非常臃肿，新人接手时理解成本陡增。而且不同团队维护的lib，命名规范本来就不统一，强行加前缀只会让混乱加剧。
第三，也是最关键的——分开编译本身就是为了让各lib保持独立。VCS的separate compilation机制允许你把每个lib编译成一个独立的simv.daidir或者.so库，lib内部的符号是私有的，只有显式导出的接口才对上层可见。这意味着你根本不需要改模块名，VCS在链接阶段会自动处理符号隔离。
所以正确的思路是：保持各lib源码原样，通过VCS的编译选项和脚本组织来实现隔离，而不是去改代码。
2.2 VCS的lib编译机制拆解
VCS处理多lib编译的核心选项是-libmap和-lib。简单来说，-libmap用来指定一个映射文件，告诉VCS哪个文件属于哪个lib；-lib用来指定当前编译的是哪个lib。编译完成后，每个lib会生成独立的库文件，放在各自的目录下。
具体流程是这样的：先对每个lib单独执行一次VCS编译，生成该lib的库文件；然后在top层编译时，通过-libmap引用这些已经编译好的库，VCS会自动从库里解析需要的模块，而不需要重新编译源码。这样做的好处是，lib可以独立编译、独立更新，某个lib改了代码只需要重新编译那个lib，top层重新链接即可，大大节省编译时间。
但这里有个关键细节：VCS的lib编译默认是“黑盒”模式，也就是说lib内部的信号对top层不可见，你没法在top层的波形里直接看lib内部的信号。如果调试时需要看内部信号，需要在编译lib时加上-debug_access+all或者-debug_access+pp之类的选项，把调试信息也打进库里。这个选项会显著增大库文件体积，所以通常的做法是：日常编译用不带debug的版本，需要调试时再重新编译带debug的lib。
另一个细节是lib之间的依赖关系。如果libA依赖libB的模块，那么编译libA时必须能访问到libB的库。VCS的处理方式是，在编译libA时通过-libmap把libB的库也映射进来，这样libA编译时就能解析到libB的模块。但要注意，libB必须已经编译完成，否则会报找不到模块。所以lib的编译顺序必须按照依赖关系拓扑排序，不能随便乱来。
2.3 重命名在什么场景下才真正需要
虽然前面说了不建议大规模改模块名，但有一种场景下重命名是必要的：当两个lib里有同名模块，且这两个lib需要被同一个top层同时引用，而你又不想让它们分别编译成独立库时。比如某些IP核，供应商提供的源码里模块名是固定的，你没法改，但你的项目里已经有一个同名模块了，这时候就需要重命名。
VCS提供了一个-module_rename选项，可以在编译时对指定模块进行重命名。用法是-module_rename old_name new_name，可以写多条。这个选项的好处是不需要改源码，只在编译阶段生效。但要注意，重命名之后，所有例化该模块的地方也需要同步重命名，否则会报找不到模块。VCS的-module_rename会自动处理例化名的替换，但前提是你的例化方式是模块名例化，而不是基于`define或者字符串拼接的例化。
还有一种更优雅的做法：用bind语句或者wrapper模块来隔离。比如你不想改原模块名，可以写一个wrapper模块，把原模块包在里面，wrapper模块用新的名字，对外暴露的接口和原模块一致。这样原模块的名字保持不变，wrapper模块的名字是新的，不会冲突。这种做法的缺点是增加了一层层次，仿真性能会略有下降，但可维护性更好。
3. 一套能直接跑的多lib编译脚本框架
3.1 目录结构设计
脚本能不能用好，首先看目录结构设计得合不合理。我推荐的结构是这样的：
project/ ├── libs/ │ ├── lib_cpu/ │ │ ├── rtl/ │ │ ├── filelist.f │ │ └── compile.cfg │ ├── lib_dsp/ │ │ ├── rtl/ │ │ ├── filelist.f │ │ └── compile.cfg │ └── lib_periph/ │ ├── rtl/ │ ├── filelist.f │ └── compile.cfg ├── top/ │ ├── rtl/ │ ├── tb/ │ ├── filelist.f │ └── compile.cfg ├── scripts/ │ ├── compile_lib.sh │ ├── compile_top.sh │ ├── compile_all.sh │ └── clean.sh ├── build/ │ ├── lib_cpu/ │ ├── lib_dsp/ │ ├── lib_periph/ │ └── top/ └── libmap.f每个lib有自己的目录，里面放RTL源码、filelist和编译配置。build目录用来存放编译产物，和源码分离，方便清理。libmap.f是全局的lib映射文件，top层编译时引用。
这个结构的好处是：每个lib的编译完全独立，互不干扰；编译产物集中管理，clean的时候直接删build目录就行；libmap.f统一维护，新增lib时只需要改这一个文件。
3.2 libmap文件的写法与坑
libmap.f的格式是这样的：
lib_cpu ./build/lib_cpu/lib_cpu.so lib_dsp ./build/lib_dsp/lib_dsp.so lib_periph ./build/lib_periph/lib_periph.so每行三个字段：lib名、库文件路径。注意路径要用相对路径或者绝对路径，不能用~，VCS不认。另外，库文件的扩展名在不同平台下可能不同，Linux下通常是.so，有些版本是.daidir目录。建议在脚本里用变量控制，不要写死。
一个常见的坑是：libmap文件里的lib名必须和编译lib时用的-lib参数一致，否则top层链接时会报找不到lib。另一个坑是，如果lib之间有依赖，libmap里必须把所有被依赖的lib都列出来，不能只列直接依赖的。比如libA依赖libB，libB依赖libC，那么编译libA时libmap里必须同时有libB和libC，否则libA编译时会报找不到libC里的模块。
还有一个隐蔽的坑：libmap文件里的路径如果是相对路径，是相对于执行VCS命令的当前目录，而不是相对于libmap文件所在的目录。所以脚本里最好先cd到项目根目录再执行VCS，或者用绝对路径。
3.3 编译脚本的核心逻辑
compile_lib.sh的核心逻辑是这样的：
#!/bin/bash # 用法: ./compile_lib.sh <lib_name> LIB_NAME=$1 if [ -z "$LIB_NAME" ]; then echo "Usage: $0 <lib_name>" exit 1 fi LIB_DIR="./libs/$LIB_NAME" BUILD_DIR="./build/$LIB_NAME" mkdir -p $BUILD_DIR # 读取该lib的编译配置 source $LIB_DIR/compile.cfg # 执行VCS编译 vcs -full64 \ -sverilog \ -timescale=1ns/1ps \ -lib $LIB_NAME \ -libmap ./libmap.f \ -f $LIB_DIR/filelist.f \ $EXTRA_OPTS \ -Mdir=$BUILD_DIR \ -o $BUILD_DIR/lib_${LIB_NAME}.so \ -l $BUILD_DIR/compile.log这里有几个关键点。-lib $LIB_NAME指定当前编译的lib名，这个名要和libmap里的名字一致。-libmap ./libmap.f引入全局映射，这样当前lib如果依赖其他lib，就能解析到。-Mdir指定编译中间文件的目录，避免污染源码目录。-o指定输出库文件名，建议用lib_${LIB_NAME}.so的格式，清晰明了。-l把编译日志写到文件里，方便排查问题。
compile.cfg里可以放该lib特有的编译选项，比如：
EXTRA_OPTS="-debug_access+all -kdb -lca"这样不同lib可以有不同的调试选项，灵活性很高。
compile_top.sh的逻辑类似，但不需要-lib参数，而是通过-libmap引用所有lib：
#!/bin/bash BUILD_DIR="./build/top" mkdir -p $BUILD_DIR vcs -full64 \ -sverilog \ -timescale=1ns/1ps \ -libmap ./libmap.f \ -f ./top/filelist.f \ -top top_module \ -Mdir=$BUILD_DIR \ -o $BUILD_DIR/simv \ -l $BUILD_DIR/compile.log注意top层编译时不需要-lib参数，VCS会自动从libmap里解析所有lib。-top指定顶层模块名，这个必须写对，否则VCS会报找不到顶层。
compile_all.sh就是把所有lib按依赖顺序编译一遍，最后编译top：
#!/bin/bash # 按依赖顺序编译 ./scripts/compile_lib.sh lib_cpu ./scripts/compile_lib.sh lib_dsp ./scripts/compile_lib.sh lib_periph ./scripts/compile_top.sh如果lib之间有依赖，顺序不能乱。比如lib_dsp依赖lib_cpu，那lib_cpu必须先编译。这个顺序建议在脚本里硬编码，或者用一个依赖描述文件来管理。
3.4 增量编译怎么配才不翻车
增量编译是省时间的关键，但配不好会翻车。VCS的增量编译依赖于-Mdir目录里的中间文件，如果中间文件被破坏或者不完整，增量编译会失败，甚至产生错误的仿真结果。
我的经验是：日常开发用增量编译，但每次跑回归之前必须做一次全量编译。增量编译的触发条件是：filelist里的文件没有增删，只是内容修改。如果filelist变了，或者编译选项变了，VCS会自动做全量编译。所以脚本里不需要额外判断，VCS自己会处理。
但有一个坑：如果某个lib的源码改了，你只重新编译了那个lib，然后重新链接top，这时候top的增量编译可能会因为库文件时间戳的问题而跳过重新链接，导致仿真用的还是旧库。解决办法是在重新编译lib之后，手动touch一下top的filelist，强制top重新链接。或者在脚本里加一个-force选项，强制全量编译。
另一个坑是：不同lib的编译选项如果差异很大，比如一个lib用了-debug_access+all，另一个没用，链接时可能会报选项冲突。建议所有lib的公共选项保持一致，差异选项放在各自的compile.cfg里，并且确保这些差异选项不会影响链接。
4. 重命名与符号隔离的实战处理
4.1 用-module_rename做精准替换
前面提到了-module_rename选项，这里展开讲一下具体用法和注意事项。假设libA里有一个模块叫fifo_ctrl，libB里也有一个fifo_ctrl，两个lib需要同时被top引用，且都编译成独立库。这种情况下其实不需要重命名，因为lib隔离已经解决了冲突。但如果因为某些原因必须合并编译，那就需要重命名。
用法示例：
vcs -full64 -sverilog \ -module_rename fifo_ctrl libA_fifo_ctrl \ -f libA_filelist.f \ -f libB_filelist.f \ ...这样libA里的fifo_ctrl会被重命名为libA_fifo_ctrl，libB里的保持不变。VCS会自动把所有例化fifo_ctrl的地方替换成libA_fifo_ctrl，但前提是例化方式是直接模块名例化。如果例化是通过`define宏或者参数化生成的，VCS可能无法正确替换，需要手动处理。
一个重要的注意事项：-module_rename的作用范围是全局的，它会把所有匹配的模块都重命名，而不是只重命名某个lib里的。所以如果你只想重命名libA里的fifo_ctrl，而libB里的保持不变，这个选项做不到。这时候就需要用wrapper模块或者改源码的方式。
4.2 wrapper模块隔离法
wrapper模块是我最推荐的重命名方案，因为它不改源码、不影响其他lib、可维护性好。具体做法是：在libA里新建一个模块libA_fifo_ctrl_wrapper，里面例化原fifo_ctrl，对外暴露的接口和原模块一致。然后在top层例化wrapper模块，而不是直接例化fifo_ctrl。
wrapper模块的写法：
module libA_fifo_ctrl_wrapper #( parameter DEPTH = 16, parameter WIDTH = 32 ) ( input wire clk, input wire rst_n, input wire wr_en, input wire [WIDTH-1:0] wr_data, output wire full, input wire rd_en, output wire [WIDTH-1:0] rd_data, output wire empty ); fifo_ctrl #( .DEPTH(DEPTH), .WIDTH(WIDTH) ) u_fifo_ctrl ( .clk (clk), .rst_n (rst_n), .wr_en (wr_en), .wr_data (wr_data), .full (full), .rd_en (rd_en), .rd_data (rd_data), .empty (empty) ); endmodule这样top层例化libA_fifo_ctrl_wrapper，libB里的fifo_ctrl不受影响。wrapper模块的名字是唯一的，不会冲突。缺点是增加了一层层次，仿真时波形里会多一层，但可以通过-debug_access选项把wrapper内部的信号也dump出来，不影响调试。
wrapper模块的另一个好处是，可以在wrapper里加一些额外的逻辑，比如信号打拍、断言检查、覆盖率采集等，而不需要改原模块。这在验证IP核时特别有用。
4.3 符号可见性控制
分开编译之后，lib内部的符号默认对top层不可见。如果top层需要引用lib内部的某个信号或者模块，需要在编译lib时显式导出。VCS提供了-export选项来导出符号，但更常用的方式是通过-debug_access选项把调试信息打进库里。
-debug_access有几个级别：-debug_access+pp是部分调试，-debug_access+all是全调试。全调试会显著增大库文件体积，但能让你在top层波形里看到lib内部的所有信号。日常开发建议用+pp，需要深度调试时再用+all。
还有一个选项是-kdb，用来生成Verdi的Knowledge Database，配合Verdi做联合仿真时必需。如果项目里用Verdi看波形，编译lib时一定要加-kdb，否则Verdi无法加载lib内部的信号。
符号可见性控制的另一个维度是-incdir和-y选项。如果libA的源码里include了libB的头文件，编译libA时需要把libB的include目录加进来。这个可以在compile.cfg里配置：
EXTRA_OPTS="-incdir ../lib_dsp/include -y ../lib_dsp/rtl +libext+.v"注意-y选项指定的目录里，VCS会自动搜索模块定义，但搜索顺序和文件命名规则有讲究，建议配合+libext+.v使用，明确指定文件扩展名。
5. 编译顺序、依赖管理与常见报错排查
5.1 依赖关系的拓扑排序
多lib编译最容易被忽视的就是依赖顺序。如果libA依赖libB，但你先编译libA，VCS会报找不到libB里的模块。解决办法是在编译libA之前，确保libB已经编译完成，并且libmap里已经包含了libB的库路径。
依赖关系可以用一个简单的文本文件来描述：
lib_cpu: lib_dsp: lib_cpu lib_periph: lib_cpu lib_dsp然后写一个Python脚本解析这个文件，做拓扑排序，生成编译顺序。这样新增lib时只需要改这个依赖文件，不需要改编译脚本。
拓扑排序的Python实现很简单：
import collections def topo_sort(deps): graph = collections.defaultdict(list) in_degree = collections.defaultdict(int) all_nodes = set() for lib, dep_list in deps.items(): all_nodes.add(lib) for dep in dep_list: graph[dep].append(lib) in_degree[lib] += 1 all_nodes.add(dep) queue = collections.deque([n for n in all_nodes if in_degree[n] == 0]) result = [] while queue: node = queue.popleft() result.append(node) for neighbor in graph[node]: in_degree[neighbor] -= 1 if in_degree[neighbor] == 0: queue.append(neighbor) if len(result) != len(all_nodes): raise ValueError("Circular dependency detected") return result这个脚本输出的是编译顺序，按这个顺序依次调用compile_lib.sh即可。
5.2 常见报错与排查链路
多lib编译的报错信息往往很隐晦，这里列几个我踩过的坑和排查方法。
报错一：Error: Module 'xxx' not found
这个报错通常是因为libmap里没有包含被依赖的lib，或者被依赖的lib还没有编译。排查步骤：先确认被依赖的lib是否已经编译成功，检查build/lib_xxx/目录下是否有库文件；然后检查libmap.f里是否包含了该lib的路径；最后确认编译当前lib时是否加了-libmap选项。
报错二：Error: Duplicate module 'xxx'
这个报错说明两个lib里有同名模块，且都被top层引用了。排查步骤：用grep -r "module xxx" libs/找到所有定义该模块的文件；确认是否真的需要两个同名模块同时存在；如果是，用wrapper模块隔离，或者用-module_rename重命名其中一个。
报错三：Error: Cannot open library 'xxx.so'
这个报错通常是路径问题。排查步骤：确认libmap里的路径是否正确，相对路径是相对于执行VCS的当前目录；确认库文件是否真的存在，有时候编译失败但脚本没报错，库文件没生成；确认库文件的权限是否可读。
报错四：仿真结果和预期不一致，但编译没报错
这种最阴险。通常是因为增量编译用了旧的库文件，或者libmap里引用了错误的库版本。排查步骤：先做一次全量编译，排除增量编译的问题；然后检查libmap里的库文件时间戳，确认是最新编译的；最后在top层加-debug_access+all，dump出lib内部的信号，对比波形确认行为。
5.3 编译日志的分析技巧
VCS的编译日志信息量很大，但很多人只看最后几行。其实日志里的warning往往比error更重要。比如Warning: Module 'xxx' is not referenced可能意味着某个模块没有被正确例化，Warning: Port 'xxx' is not connected可能意味着接口信号漏连了。
我的习惯是：每次编译后，用grep -i "warning\|error" compile.log快速过一遍，把warning也当成error来对待。特别是多lib编译时，lib之间的接口信号如果漏连，VCS可能只报warning不报error，但仿真行为会完全错误。
另外，日志里的Parsing、Elaborating、Linking三个阶段的时间戳很有用。如果Parsing时间很长，说明源码文件太多，可以考虑优化filelist；如果Elaborating时间很长，说明层次太深或者参数化太复杂；如果Linking时间很长，说明lib之间的依赖关系太复杂，可以考虑合并一些lib。
6. 脚本优化与团队协作的落地经验
6.1 让脚本支持并行编译
多lib编译的一个天然优势是，没有依赖关系的lib可以并行编译。比如lib_cpu和lib_periph如果没有依赖关系，可以同时编译，节省时间。在脚本里可以用&和wait实现：
#!/bin/bash ./scripts/compile_lib.sh lib_cpu & ./scripts/compile_lib.sh lib_periph & wait ./scripts/compile_lib.sh lib_dsp ./scripts/compile_top.sh但并行编译有个坑：如果两个lib同时写同一个libmap文件，会冲突。解决办法是每个lib用独立的libmap副本，或者用文件锁。我通常的做法是，并行编译的lib之间确保没有依赖关系，且各自用独立的build目录，libmap文件只读不写，这样就不会冲突。
另一个坑是CPU资源竞争。如果机器核数不够，并行编译反而更慢。建议根据机器核数控制并行度，比如nproc命令获取核数，然后限制同时编译的lib数量。
6.2 编译缓存的利用
VCS本身有编译缓存机制，但多lib场景下缓存容易失效。我的经验是：把-Mdir目录保留下来，不要每次clean都删。VCS会根据源码时间戳和编译选项判断是否需要重新编译，如果源码没变，直接复用缓存，速度极快。
但要注意，如果编译选项变了，缓存会失效，VCS会重新编译。所以建议把编译选项也纳入版本管理，每次改选项时在commit message里写清楚，避免团队成员之间选项不一致导致缓存频繁失效。
还有一个技巧是：把不常变的lib（比如第三方IP）编译一次之后，把库文件和-Mdir目录一起打包，放到共享目录里。团队成员直接引用这个预编译库，不需要自己编译。这样能大幅节省新人的环境搭建时间。
6.3 团队协作中的脚本规范
多lib项目通常是团队协作，脚本的规范性直接影响协作效率。我总结了几条规范：
第一，脚本必须支持-h或--help选项，打印用法说明。新人拿到脚本第一件事就是看帮助，没有帮助文档的脚本会被吐槽。
第二，脚本必须支持clean选项，一键清理编译产物。清理时要区分“清理当前lib”和“清理所有lib”，避免误删别人的编译结果。
第三，脚本必须把关键信息输出到日志文件，而不是只打印到终端。终端输出会被刷掉，日志文件可以事后排查。
第四，脚本里的路径必须用变量，不能硬编码。比如PROJ_ROOT=$(cd $(dirname $0)/..; pwd)，这样脚本在任何目录下执行都能找到项目根目录。
第五，脚本必须做参数校验。比如compile_lib.sh如果不传lib名，应该报错退出，而不是默默编译一个空lib。
6.4 和Verdi联合仿真的配置
如果项目里用Verdi看波形，多lib编译时需要额外注意。编译lib时要加-kdb选项生成KDB文件，top层编译时也要加-kdb，并且通过-libmap引用lib的KDB。Verdi加载时，需要把lib的KDB路径也加进去，否则看不到lib内部的信号。
具体配置：
# 编译lib时 vcs -full64 -sverilog -kdb -debug_access+all -lib lib_cpu ... # 编译top时 vcs -full64 -sverilog -kdb -debug_access+all -libmap ./libmap.f ... # Verdi加载时 verdi -dbdir ./build/top/simv.daidir -ssf ./wave.fsdb -nologo &如果Verdi里看不到lib内部信号，检查两个地方：一是编译lib时是否加了-kdb和-debug_access+all；二是Verdi的-dbdir是否指向了top的daidir，且libmap里的库路径是否正确。
还有一个坑是，如果lib编译时用了-debug_access+all，但top编译时没用，Verdi可能只能看到top层的信号，看不到lib内部的。所以建议top和lib的debug选项保持一致。
7. 一些零散但重要的实操心得
7.1 filelist的维护技巧
filelist是编译的入口，维护不好会出大问题。我的习惯是：每个lib的filelist只包含该lib自己的文件，不要跨lib引用。如果libA需要libB的文件，通过libmap引用libB的库，而不是把libB的文件加到libA的filelist里。这样lib的边界清晰，依赖关系明确。
filelist里的路径建议用相对路径，相对于filelist文件所在目录。VCS的-f选项支持在filelist里用-f嵌套引用其他filelist，但嵌套层数不要超过两层，否则排查问题很麻烦。
另外，filelist里不要写+incdir+和+define+，这些编译选项应该放在compile.cfg里，和filelist分离。filelist只负责列文件，编译选项负责控制编译行为，职责分离。
7.2 编译时间的优化
多lib编译的时间主要花在三个地方：Parsing、Elaborating、Linking。优化手段包括：
- 减少不必要的文件：filelist里只列真正需要的文件，不要用
-y选项自动搜索整个目录。 - 用
-sverilog而不是-vlogan：如果代码是SystemVerilog，直接用-sverilog，VCS会优化解析流程。 - 用
-fast选项：VCS的-fast选项可以加速编译，但会牺牲一些调试能力，适合日常快速验证。 - 并行编译：前面说了，没有依赖关系的lib并行编译。
- 增量编译：源码没变时复用缓存，避免重复编译。
实测下来，一个中等规模的多lib项目（5个lib，总共约2000个文件），全量编译约15分钟，增量编译约2分钟，并行编译约8分钟。优化效果还是很明显的。
7.3 版本管理与编译产物的关系
编译产物（build目录）不要纳入版本管理，但libmap.f和compile.cfg要纳入。libmap.f里的路径建议用相对路径，这样不同机器上clone下来就能直接用。compile.cfg里的编译选项要写清楚注释，说明每个选项的作用，方便后人维护。
如果项目里用了Git，建议在.gitignore里加上build/和*.so，避免编译产物被误提交。同时建议在README.md里写清楚编译步骤，新人照着做就能跑通。
7.4 跨平台编译的注意事项
如果项目需要在Linux和Windows下都能编译，脚本要兼容两个平台。VCS在Windows下的路径分隔符是反斜杠，Linux下是正斜杠，脚本里要用变量控制。另外，Windows下VCS的库文件扩展名可能是.dll而不是.so，libmap里要相应调整。
我的做法是：用uname命令判断平台，然后设置不同的变量：
if [ "$(uname)" == "Linux" ]; then LIB_EXT=".so" PATH_SEP="/" else LIB_EXT=".dll" PATH_SEP="\\" fi这样脚本在两个平台下都能跑，不需要手动改。
7.5 一个容易被忽视的细节：时间戳
VCS的增量编译依赖文件时间戳。如果从版本管理里clone下来的文件时间戳都是clone时间，VCS会认为所有文件都是新的，做全量编译。解决办法是：clone之后先做一次全量编译，之后增量编译就正常了。或者在脚本里用touch命令把源码文件的时间戳改成和库文件一致，但这样有风险，不建议。
另一个时间戳的坑是：如果系统时间被调整过（比如时区变了），文件时间戳可能比库文件还新，导致VCS误判需要重新编译。这种情况很少见，但一旦遇到很难排查。建议在脚本里加一个-force选项，强制全量编译，作为兜底方案。
8. 最后再聊几句实际项目里的取舍
多lib编译这套东西，说到底是在“编译速度”和“调试便利性”之间做取舍。lib分得越细，编译越快，但lib之间的接口调试越麻烦；lib分得越粗，调试越方便，但编译时间越长。我的经验是：按功能模块划分lib，每个lib的规模控制在500到1000个文件之间，这样编译速度和调试便利性比较平衡。
另外，不要为了用多lib而用多lib。如果项目规模不大，一个lib能搞定，就别折腾。多lib编译的复杂度不低，脚本维护、依赖管理、调试配置都需要投入精力。只有当项目规模大到单lib编译时间超过10分钟，或者确实存在模块名冲突时，才值得上多lib方案。
脚本这东西，写一次用很久，所以值得花时间打磨。我现在的脚本框架是经过五六个项目迭代出来的，基本能覆盖大部分场景。但每个项目都有特殊性，拿到脚本后还是要根据实际情况调整。比如有些项目用Makefile管理编译，有些用Python脚本，有些直接写shell，选自己团队最熟悉的就好，没必要追求统一。
最后分享一个小技巧：在脚本里加一个-dry-run选项，只打印将要执行的VCS命令，不实际执行。这样调试脚本时很方便，能快速确认命令拼得对不对，避免因为脚本bug浪费编译时间。这个技巧在排查编译报错时特别有用，能快速定位是脚本问题还是VCS问题。
