package_id()

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

一般规则是,settingsoptions 的每个不同值都会创建一个不同的 package_id。这个规则可以通过不同的方法来放宽或扩展。

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

  • 给定的包配方可以实现一些信息的局部擦除,例如,为了获得一系列编译器版本相同的 package_id。这种二进制兼容性通常最好通过全局 compatibility 插件,或者如果全局插件不足,则通过 compatibility() 方法来处理。

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

可用的自动实现

警告

此功能是实验性的,可能会发生重大更改。有关更多信息,请参阅 Conan 稳定性 部分。

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

auto_header_only

当配方声明一个选项 header_only=True 或当 package_type"header-library" 时,Conan 将自动管理清除设置和选项的包 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.settingsself.options 上。

如果一个包只是一个 C 库,但它无法在 configure() 方法中删除 compiler.cppstdcompiler.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")

如果一个包正在构建一个可执行文件作为工具,并且只希望为每个操作系统和架构生成一个可执行文件以提高效率,那么 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

请注意,这并不意味着 compilerbuild_type 应该被删除以用于每个应用程序可执行文件。对于其他不是工具而是最终产品的项目,最常见的情况是为不同的编译器、编译器版本、构建类型等维护不同的构建是最好的方法。这也意味着我们正在擦除一些信息。我们将无法获取用于我们正在使用的二进制文件的编译器和构建类型的信息(它不会出现在 conan list 输出中,也不会出现在服务器元数据中)。如果我们使用不同的编译器或构建类型编译新二进制文件,它将在相同的 package_id 下创建一个新的包修订版本。

局部信息擦除

还可以对给定的值子集局部擦除信息。例如,如果我们希望所有使用 gcc 在 4.5 和 5.0 版本之间编译的二进制文件具有相同的 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 版本,将只有一个 package_id 二进制文件。这也有前面提到的关于丢失创建此二进制文件的信息的问题。

一般情况下不推荐这种方法,并且最好通过全局 compatibility 插件或配方 compatibility() 方法来处理。

注意

不仅 settings 可以被擦除,其他所有类型的信息,如 optionsconf 项也可以。

添加信息

有些信息默认不会添加到 package_id。如果我们正在为工具创建包,用作 tool_require,并且该包的二进制文件对于每个“目标”配置都不同,就像某些交叉编译器的情况一样,如果编译器本身对于它所针对的不同架构可能不同,那么就需要使用以下方法将 settings_target 添加到 package_id 中:

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

conf 项默认不影响 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”开头的配置。

另请参阅