16 加快构建

构建耗时可能成为问题。默认情况下，构建系统通过简单控制尽可能提高效率。 对于单插槽系统，即只有一颗 CPU 的系统，以下变量的默认设置通常能获得最高的 构建效率。如果有多颗 CPU，可以尝试提高默认值以加快构建。更多信息见各变量 的词汇表说明：

• BB_NUMBER_THREADS：BitBake 同时执行的最大线程数。

• BB_NUMBER_PARSE_THREADS：BitBake 在解析阶段使用的线程数。

• PARALLEL_MAKE：在 do_compile 任务中传递给 make 的额外选项，用于指定在本地构建主机上并行编译。

• PARALLEL_MAKEINST：在 do_install 任务中传递给 make 的额外选项，用于指定在本地构建主机上并行安装。

这些变量都会根据构建系统可用的处理器核心数调整。对于单插槽系统，这种自动 调整能确保构建系统根据机器能力利用构建期间的并行执行机会。

其他影响构建速度的因素包括：

• 文件系统类型：构建所在文件系统也会影响性能。相比 ext2 和 ext3， 推荐使用 ext4，因为它提供了 extents 等改进功能。

• 使用 noatime 禁止更新访问时间：此挂载选项阻止构建系统更新文件和目录 的访问时间。

• 延长提交间隔：使用 "commit=" 挂载选项可以增大磁盘缓存写入间隔，单位为秒。 将默认的 5 秒间隔调长，会增加数据丢失风险，但能减少磁盘写入，提高构建性能。

• 选择打包后端：现有后端中，IPK 最快。另外，只选择一种打包后端也有帮助。

• 将 TMPDIR 放在 tmpfs 临时文件系统上：这有助于加快构建，但 由于编译器使用 -pipe，收益有限。构建系统尽力避免对文件系统调用 sync()，其依据是即使发生严重故障，Build Directory 的内容 也很容易重新构建。

• 继承 rm_work 类：实践表明，该类显著减少了数据缓存和 磁盘中保存的数据量，从而加快构建。它还加快了 TMPDIR 的清理， 代价是不再方便直接查看源码。文件系统维护者建议，考虑到分区的线性特性， 清理大量文件最快的方法是重新格式化分区，而不是逐个删除文件。当然，这 要求磁盘分区和文件系统的组织方式允许这样做。

除上述因素外，还可以考虑以下取舍来加快构建：

• 从 DISTRO_FEATURES 中移除不需要的项目。

• 排除调试符号和其他调试信息：如果不需要这些内容，可以禁止生成 *-dbg 软件包以加快构建。将 INHIBIT_PACKAGE_DEBUG_SPLIT 设为 "1" 即可。

• 对基于 autoconf 或 libtool 的配方禁用静态库生成。以下示例禁用 静态库，同时通过覆盖处理例外情况:

  STATICLIBCONF = "--disable-static"
  STATICLIBCONF:sqlite3-native = ""
  EXTRA_OECONF += "${STATICLIBCONF}"
  

  备注

  • 一些配方需要静态库才能正常工作，例如 pseudo-native 需要 sqlite3-native。可以像上例一样使用覆盖处理这些例外。

  • 某些软件包的打包代码假定静态库存在，这种情况下可能也需要将其排除。