自定义二进制兼容性¶

默认二进制兼容性要求设置和选项几乎完全匹配，以及依赖项版本的版本匹配，如前面关于依赖项的部分所述。

总之，安装依赖项时所需的二进制文件 package_id 默认情况下应匹配。

package_id 中的所有设置（compiler.cppstd 除外）都应与输入配置文件中提供的设置完全匹配，包括编译器版本。因此，compiler.version=9 与 compiler.version=9.1 不同。
默认行为将假设不同 compiler.cppstd 值的 C++ 包之间存在二进制兼容性，能够回退到其他值而不是输入配置文件中指定的 cppstd，如果输入配置文件所需的 cppstd 不存在。这由 compatibility.py 插件控制，用户可以自定义该插件。
package_id 中的所有选项都应与输入配置文件中提供的选项完全匹配。
依赖项的版本应匹配。
- 对于“嵌入依赖项”的情况，应匹配确切的版本，包括配方修订版和依赖项 package_id。 package_revision 从未包含在内，因为它假设对于相同的 package_id 拥有多个 package_revision 形式不佳。
- 对于“非嵌入依赖项”的情况，依赖项的版本应匹配到 minor 版本，patch、recipe_revision 和其他信息不予考虑。
- 对于“工具依赖项”的情况，依赖项的版本默认情况下不会影响使用者 package_id。

这些规则可以使用不同的方法进行自定义和更改，具体取决于需要，如下面的部分所述。

自定义设置和选项的二进制兼容性¶

在 package_id() 方法中擦除信息¶

配方可以使用其 package_id() 方法从其 package_id 中擦除信息。例如，仅包含可执行文件的包可以决定从其 package_id 中删除 settings.compiler 和 settings.build_type 的信息，假设使用任何编译器构建的可执行文件都是有效的，并且不需要存储使用不同编译器构建的不同二进制文件。

def package_id(self):
    del self.info.settings.compiler
    del self.info.settings.build_type

也可以为给定设置分配一个值，例如，如果我们希望对 [>=5 <7>] 范围内的所有 gcc 版本使用一个二进制文件，我们可以执行以下操作。

def package_id(self):
    if self.info.settings.compiler == "gcc":
        version = Version(self.info.settings.compiler.version)
        if version >= "5.0" and version < "7.0":
            self.info.settings.compiler.version = "gcc5-6"

注意

最佳实践

请注意，在 package_id() 中擦除信息意味着 1 个 package_id 将表示一系列不同的设置，但用于创建二进制文件的精确设置信息将丢失，并且只能为该范围创建 1 个二进制文件。使用该范围内不同的设置重新创建包将创建一个新的二进制文件，该文件将覆盖上一个二进制文件（使用新的包修订版）。

如果我们希望能够为不同的输入设置创建、存储和管理不同的二进制文件，则不能使用信息擦除，建议使用以下 compatibility 方法。

另请参阅

compatibility() 方法¶

配方可以使用其 compatibility() 方法定义其二进制兼容性规则。例如，如果我们希望使用 gcc 版本 4.8、4.7 和 4.6 构建的二进制文件被认为与使用 4.9 编译的二进制文件兼容，我们可以声明一个类似于以下内容的 compatibility() 方法。

def compatibility(self):
    if self.settings.compiler == "gcc" and self.settings.compiler.version == "4.9":
        return [{"settings": [("compiler.version", v)]}
                for v in ("4.8", "4.7", "4.6")]

在compatibility() 方法参考中阅读有关 compatibility() 方法的更多信息。

compatibility.py 插件¶

可以通过 compatibility.py 插件全局定义兼容性，就像 compatibility() 方法对一个配方执行操作一样，但对所有包全局执行操作。

检查二进制兼容性compatibility.py 扩展。

自定义依赖项版本的二进制兼容性¶

全局默认 package_id 模式¶

在 global.conf 中定义的 core.package_id:default_xxx 配置可用于全局更改依赖项如何影响其使用者的默认设置。

core.package_id:default_build_mode: By default, 'None'
core.package_id:default_embed_mode: By default, 'full_mode'
core.package_id:default_non_embed_mode: By default, 'minor_mode'
core.package_id:default_python_mode: By default, 'minor_mode'
core.package_id:default_unknown_mode: By default, 'semver_mode'

注意

最佳实践

强烈建议 core.package_id:default_xxx 应在组织范围内保持全局、一致和不变。对于不同的项目或团队更改这些默认设置可能会令人困惑，因为这会导致丢失二进制文件。

如果这些包在组织外部共享，那么它也应与生成的包的使用者保持一致并共享，在这种情况下，建议通过 conan config install 共享 global.conf 文件。

考虑使用 Conan 默认值，它们应该是在效率和安全性之间取得良好平衡，确保在嵌入情况下精确重新构建，并在非嵌入情况下通过版本进行良好的控制。

配方使用者的自定义 package_id 模式¶

配方可以通过一些 package_id_xxxx_mode 属性定义其对使用者的默认影响。

package_id_embed_mode, package_id_non_embed_mode, package_id_unknown_mode 是可以在配方中定义的类属性，以定义它们对使用者 package_id 的影响。可以声明为

from conan import ConanFile

class Pkg(ConanFile):
    ...
    package_id_embed_mode = "full_mode"
    package_id_non_embed_mode = "patch_mode"
    package_id_unknown_mode = "minor_mode"

在package_id_{embed,non_embed,python,unknown}_mode中阅读更多信息。

来自配方依赖项的自定义 package_id¶

配方可以使用 package_id_mode 特性定义其依赖项如何影响其 package_id。

from conan import ConanFile

class Pkg(ConanFile):
    def requirements(self):
        self.requires("mydep/1.0", package_id_mode="patch_mode")

使用 package_id_mode 特性不会区分“嵌入”和“非嵌入”情况，用户需要定义正确的值。这种方法可能仅适用于非常特殊的情况，这些情况没有通过 options 控制共享/静态库的可变性。

请注意，requirements() 方法在图正在扩展时进行评估，依赖项尚不存在（尚未计算），因此无法知道依赖项选项。在这种情况下，可能更倾向于使用 package_id() 方法。

package_id() 方法可以使用以下方法定义依赖项如何影响当前包。

from conan import ConanFile

class Pkg(ConanFile):
    def package_id(self):
        self.info.requires["mydep"].major_mode()

可在package_id_{embed,non_embed,python,unknown}_mode中定义可使用的不同模式。