build_id()¶

build_id() 方法允许重用相同的构建来在缓存中创建不同的二进制包，这可以避免一些不必要的重复构建，从而可能节省构建时间。因此，它是一种优化方法。

一般情况下，每个二进制包都有一个构建文件夹，其 package_id 与包的完全相同。然而，这种行为可以改变，有几种情况下这可能会很有用：

包的构建脚本在同一次运行中同时生成多个不同的配置（例如调试和发布构件），而无法单独构建每个配置。
包的构建脚本生成一个二进制配置，但可以单独打包不同的构件。例如，如果有一些测试可执行文件，您可能希望创建两个包：一个只包含用于一般用途的库，另一个还包含测试（用于合规性、后续可重现性、调试等）。

在第一种情况下，我们可以这样写：

settings = "os", "compiler", "arch", "build_type"

def build_id(self):
    self.info_build.settings.build_type = "Any"

这个配方将为调试和发布配置生成一个带有不同 package_id 的最终不同包。但是，由于 build_id() 会为任何 build_type 生成相同的 build_id，因此只会有一个文件夹和一个 build() 被执行，同时构建调试和发布构件，然后会针对每个配置调用 package() 方法，并且它应该根据 self.settings.build_type 的值有条件地打包构件。如果使用不同的编译器或架构，仍将执行不同的构建。

其他信息，例如自定义包选项，也可以更改

def build_id(self):
    self.info_build.options.myoption = 'MyValue' # any value possible
    self.info_build.options.fullsource = 'Always'

如果 build_id() 方法不修改 info_build 数据，并且它仍然生成与 package_id 不同的 ID，那么将应用标准行为。请考虑以下情况：

settings = "os", "compiler", "arch", "build_type"

def build_id(self):
    if self.settings.os == "Windows":
        self.info_build.settings.build_type = "Any"

只有当包是针对 Windows 时，这才会产生不同的 build_id，从而对于所有 build_type 值，build() 只运行一次。在任何其他操作系统中，行为将是标准的，就像没有定义 build_id() 方法一样，每个 build_type 都会运行一次不同的 build()。

注意

最佳实践

Conan 强烈建议为每个不同的配置使用一个带有其自己的 package_id 的包二进制文件。build_id() 方法的目标是处理那些难以更改为每次只构建一个配置的传统构建脚本。