扩展二进制模型

有一些机制可以扩展默认的 Conan 二进制模型

自定义设置

可以在 settings.yml 文件中添加新的设置或子设置,如下所示:

os:
    Windows:
        new_subsetting: [null, "subvalue1", "subvalue2"]
new_root_setting: [null, "value1", "value2"]

其中 null 值允许在配置文件中保留未定义的设置。如果不包含,则配置文件必须为它们定义一个值。

自定义设置将在配方和包中显式或隐式使用

class Pkg(ConanFile):
    # If we explicilty want this package binaries to vary according to 'new_root_setting'
    settings = "os", "compiler", "build_type", "arch", "new_root_setting"
    # While all packages with 'os=Windows' will implicitly vary according to 'new_subsetting'

另请参阅

有关如何自定义 settings.yml 文件的完整参考,请访问设置部分。实际上,没有必要修改 settings.yml 文件,而是可以提供 settings_user.yml 文件来扩展现有设置。请参阅settings_user.yml 文档

自定义选项

Options 对于每个配方都是自定义的,没有像 settings.yml 那样的全局选项定义。

conanfile.py 配方定义了自己的选项,具有自己的有效值范围和默认值

class MyPkg(ConanFile):
    ...
    options = {"build_tests": [True, False],
               "option2": ["ANY"]}
    default_options = {"build_tests": True,
                        "option1": 42,
                        "z*:shared": True}

选项 sharedfPICheader_only 对 Conan 具有特殊含义,并且大多数内置的构建系统集成会自动考虑它们。它们也是表示库是共享的、静态的还是仅包含头文件的建议默认值。

设置 vs 选项 vs conf

何时使用设置或选项或配置?

  • 设置是项目范围的配置,通常会影响正在构建的整个项目并影响生成的包二进制文件。例如,操作系统或架构对于依赖关系图中的所有包通常是相同的,将 Linux 库链接到构建 Windows 应用程序,或混合架构是不可能的。设置不能在包配方中默认为值。给定库的配方不能说其默认值为 os=Windowsos 将由处理该配方的环境给出。它是输入配置文件中必须定义的输入。

  • 另一方面,选项是特定于包的配置,会影响生成的包二进制文件。静态或共享库不是适用于所有包的设置。有些可以是仅包含头文件的库,而其他包可以是仅包含数据或可执行文件的包。例如,shared 是一个常见选项(用于指定库是静态的还是共享的默认值),但是包可以定义和使用它们想要的任何选项。选项在包 conanfile.py 配方中定义,包括其支持和默认值,使用 optionsdefault_options

  • 通过 conf 进行配置适用于在一般情况下不影响生成的包二进制文件的配置。例如,使用 tools.cmake.cmaketoolchain:generator=Ninja 构建一个库不应导致与使用 Visual Studio 构建的二进制文件不同(通常只是由于 Ninja 而构建速度更快)。

以上内容有一些例外。例如,可以使用 <pattern:>setting=value 在配置文件和命令行中为每个包定义设置

$ conan install . -s mypkg/*:compiler=gcc -s compiler=clang ..

这将对 “mypkg” 使用 gcc,对其余依赖项使用 clang(在大多数情况下,建议对整个依赖关系图使用相同的编译器,但在保证强大的二进制兼容性的某些情况下,可以混合使用使用不同编译器构建的库)。

在某些情况下,许多包使用相同的选项值,从而允许您使用模式设置其值,例如

$ conan install . -o *:shared=True

自定义配置

如上所述,Conan conf 配置系统旨在调整一些工具和行为,但不会真正影响生成的包二进制文件。一些典型的 conf 项是激活并行构建、配置上传到服务器时的“重试”或更改 CMake 生成器。请在此部分中阅读有关Conan 配置系统的更多信息

还可以为用户定义的配置定义 user.xxxx:conf=value,这与核心和工具内置配置的精神相同,不影响二进制文件的 package_id

但是,在某些特殊情况下,确实希望某些 conf 定义不同的 package_ids,从而创建不同的包二进制文件。可以在两个不同的地方执行此操作

  • 在本地,在配方的 package_id 方法中,通过 self.info.conf 属性

    def package_id(self):
        # We can get the value from the actual current conf value, or define a new value
        value = self.conf.get("user.myconf:myitem")
        # This ``self.info.conf`` will become part of the ``package_id``
        self.info.conf.define("user.myconf:myitem", value)
    
  • 全局,使用 tools.info.package_id:confs 配置,接收作为参数的现有配置列表,作为包 ID 的一部分,因此您可以在配置文件中定义

    tools.info.package_id:confs=["tools.build:cxxflags", ...]
    

    package_id 的值将包含 tools.build:cxxflags 和其他配置中提供的值。请注意,此值是作为字符串管理的,更改字符串将产生不同的结果和不同的 package_id,因此如果使用此方法,则对于 tools.build:cxxflags 等不同配置提供的的值,必须保持高度一致。

    也可以使用正则表达式来匹配多个 confs,而不是列出所有 confs,例如 .*cmake 可以匹配名称中包含 “cmake” 的任何配置(不建议这样做,请参阅下面的最佳实践)。

注意

最佳实践

通常,应保留通过 conf 定义二进制文件 package_id 的可变性以用于特殊情况,并始终谨慎管理。将许多不同的 confs 传递给 tools.info.package_id:confs 很容易导致诸如缺少二进制文件或不必要地构建过多二进制文件的问题。如果是这种情况,请考虑使用新的自定义设置或选项在二进制文件上构建更高级别的抽象。

交叉构建目标设置

self.settings_target 是一个 conanfile.py 属性,在 “build” 上下文中,对于 tool_requires 工具的交叉编译场景中变得相关。当我们有一个像 CMake 这样的 tool_requires 时,假设是 cmake/3.25.3,则该包二进制文件独立于交叉编译将可能面向的平台,对于所有不同的目标平台,它是相同的 cmake 可执行文件。从 Windows-X64 到 Linux-armv8 的交叉构建场景中,cmake conanfile 配方的 settings 将是

  • self.settings:当前 cmake/3.25.3 运行的设置。因为它是一个工具依赖,它将在 Windows 机器上运行,所以 self.settings.os = Windowsself.settings.arch = x86_64

  • self.settings_build:当前构建机器的设置,如果需要,它将构建此包。这也是 Windows-x64 机器,所以 self.settings_build.os = Windowsself.settings_build.arch = x86_64

  • self.settings_target:当前应用程序输出将面向的目标设置。在这种情况下,它将是 self.settings_target.os = Linuxself.settings_target.arch = armv8

正如我们指出的,在 cmake 包场景中,目标是不相关的。它根本不用于 cmake 的 conanfile 配方中,并且不会影响 cmake 二进制包的 package_id

但是,在某些情况下,二进制包可以根据目标平台而有所不同。例如,一个交叉编译器 gcc,它根据要编译的目标具有不同的 gcc 可执行文件。这在 GNU 生态系统中很典型,我们可以在其中找到 arm-gcc 工具链,例如,特定于给定架构的。这种情况可以通过 Conan 来反映,使用这些 settings_target 的值来扩展 package_id

def package_id(self):
    self.info.settings_target = self.settings_target
    # If we only want the ``os`` and ``arch`` settings, then we remove the other:
    self.info.settings_target.rm_safe("compiler")
    self.info.settings_target.rm_safe("build_type")