build_id()¶

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

在一般情况下，每个二进制包都有一个构建文件夹，并且包的 package_id 完全相同。但是，可以更改此行为，在以下几种情况下可能很有用：

包构建脚本一次生成几个不同的配置（例如 debug 和 release 工件），并且无法单独构建每个配置。
包构建脚本生成一个二进制配置，但可以单独打包不同的工件。例如，如果有一些测试可执行文件，您可能想要创建两个包：一个仅包含用于常规用途的库，另一个还包含测试（用于合规性、以后的可重现性、调试等）。

在第一种情况下，我们可以例如编写

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

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

此配方将为 debug 和 release 配置生成最终的不同的包，并具有不同的 package_id。但是，由于 build_id() 将为任何 build_type 生成相同的 build_id，因此只会创建一个文件夹和一个 build()，构建 debug 和 release 工件，然后将为每个配置调用 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() 方法 的目标是处理遗留的构建脚本，这些脚本无法轻易更改为每次执行一个配置的构建。