package_id()

Conan 为每个配置计算一个唯一的 package_id 引用，包括 settings、options 和 dependencies 版本。此 package_id() 方法允许对计算出的 package_id 进行一些自定义和更改，通常是为了放宽一些全局二进制兼容性假设。

一般规则是，settings 和 options 的每个不同值都会创建一个不同的 package_id。可以采用不同的方法来放宽或扩展此规则

  • 一个给定的包配方可以在其 package_id() 中决定最终二进制文件独立于某些设置，例如，如果它是一个仅头文件库，使用输入设置构建一些测试，它可以完全清除所有配置，以便结果 package_id 始终相同，无论输入如何。同样，C 库可能希望从其二进制 package_id 中移除 compiler.cppstd 和/或 compiler.libcxx 的影响，因为作为 C 库，其二进制文件将是独立的。

  • 一个给定的包配方可以实现部分信息擦除，例如为了获得一系列编译器版本的相同 package_id。这种类型的二进制兼容性通常通过全局 compatibility 插件更好地解决，如果全局插件不足，则使用 compatibility() 方法解决。

  • 包配方可以决定在其计算的 package_id 中注入额外的可变性，添加 conf 项或“target”设置。

可用的自动实现

警告

此特性是实验性的，可能会发生破坏性更改。有关更多信息，请参阅Conan 的稳定性部分。

当未定义 package_id() 方法时，可以在 implements ConanFile 属性中指定以下自动实现

auto_header_only

当配方声明选项 header_only=True 或 package_type 为 "header-library" 时，Conan 将自动管理清除设置和选项的 package ID。可以像这样将其添加到配方中

from conan import ConanFile

class Pkg(ConanFile):
    implements = ["auto_header_only"]
    ...

然后，如果在配方中未指定 package_id() 方法，Conan 将自动管理它，并在 package_id() 中自动调用 self.info.clear()，使 package_id 独立于设置、选项、配置和依赖。

如果您需要在配方中实现自定义行为，但同时也需要此逻辑，则必须显式声明，例如像这样

def package_id(self):
    if self.package_type == "header-library":
        self.info.clear()
    else:
        self.info.settings.rm_safe("compiler.libcxx")
        self.info.settings.rm_safe("compiler.cppstd")

信息擦除

这是一种 package_id 放宽策略。让我们检查第一个情况：一个仅头文件库，它有输入 settings，因为它仍然想在 build() 方法中使用它们进行一些单元测试。为了在所有配置中只有一个最终二进制文件，因为最终构建产物在所有情况下都应相同（只有头文件），有必要执行以下操作

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

def build(self):
    cmake = CMake(self) # need specific settings to build
    ...
    cmake.test()  # running unit tests for the current configuration

def package_id(self):
    # Completely clear all the settings from the ``package_id`` information ("info" object)
    # All resulting ``package_id`` will be the same, irrespective of configuration
    self.info.settings.clear()

警告

对信息的修改始终发生在 self.info 对象上，而不是在 self.settings 或 self.options 上

如果一个包只是一个 C 库，但它无法在 configure() 方法中移除 compiler.cppstd 和 compiler.libcxx（这是大多数情况下的推荐方法，以确保构建中不使用这些标志），因为存在针对 C 库的 C++ 单元测试，那么由于测试未被打包，并且最终二进制文件将独立于 C++，可以使用以下方法移除这些信息

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

def build(self):
    # building C++ tests for a C library

def package_id(self):
    del self.info.settings.compiler.cppstd
    # Some compilers might not declare libcxx subsetting
    self.info.settings.rm_safe("compiler.libcxx")

如果一个包正在构建一个用作工具的可执行文件，并且为了提高效率，只希望为每个操作系统和架构生成 1 个可执行文件，package_id() 可以移除存在的其他设置和选项

# this will be a "tool_require"
package_type = "application"
settings = "os", "compiler", "arch", "build_type"

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

请注意，这并不意味着应该为每个应用程序可执行文件移除 compiler 和 build_type。对于不是工具，而是最终发布产品的情况，最常见的情况是为不同的编译器、编译器版本、构建类型等维护不同的构建是最佳方法。这也意味着我们正在擦除一些信息。我们将不会拥有我们正在使用的二进制文件所使用的编译器和构建类型的信息（它不会出现在 conan list 输出中，也不会出现在服务器元数据中）。如果我们使用不同的编译器或构建类型编译新的二进制文件，它将在相同的 package_id 下创建一个新的包修订版。

部分信息擦除

还可以针对给定值的子集部分擦除信息。例如，如果我们想让所有使用 4.5 到 5.0 版本之间的 gcc 编译的二进制文件拥有相同的 package_id，我们可以这样做

def package_id(self):
    v = Version(str(self.info.settings.compiler.version))
    if self.info.settings.compiler == "gcc" and (v >= "4.5" and v < "5.0"):
        # The assigned string can be arbitrary
        self.info.settings.compiler.version = "GCC 4 between 4.5 and 5.0"

这将导致除 gcc 以外的所有其他编译器以及不在该范围内的其他版本拥有不同的 package_id，但所有 gcc 4.5-5.0 版本将只有 1 个 package_id 二进制文件。这也有上述提及的关于丢失创建此二进制文件的信息的缺点。

在一般情况下不推荐使用此方法，最好使用全局 compatibility 插件或配方 compatibility() 方法来解决。

注意

不仅 settings 可以被擦除，其他所有类型的信息，如 options 和 conf 项也可以被擦除。

添加信息

默认情况下，package_id 中未添加一些信息。如果我们正在创建一个用作 tool_require 的工具包，并且该包的二进制文件对于每个“目标”配置都不同，就像某些交叉编译器的情形一样，如果编译器本身对于其目标的不同架构可能不同，则需要将 settings_target 添加到 package_id 中，如下所示

def package_id(self):
    self.info.settings_target = self.settings_target

的 conf 项默认不影响 package_id。可以在配方级别通过以下方式显式地将它们作为 package_id 的一部分

def package_id(self):
    self.info.conf.define("user.myconf:myitem", self.conf.get("user.myconf:myitem"))

尽管对于所有配方，无需 package_id() 方法也可以实现这一点，只需使用 tools.info.package_id:confs = ["user.myconf:myitem"] 配置即可。

使用正则表达式模式：您可以在 tools.info.package_id:confs 中使用正则表达式模式。这意味着您可以不用指定每个单独的配置项，而是使用正则表达式模式来匹配多个配置。这在处理大量配置或配置遵循可预测命名模式时特别有用。例如

  • tools.info.package_id:confs=[".*"] 匹配所有配置。

  • tools.info.package_id:confs=["tools\..*"] 匹配以“tools.”开头的配置。

  • tools.info.package_id:confs=["(tools\.deploy|core)"] 匹配以“tools.deploy”或“core”开头的配置。

另请参阅