扩展二进制模型

有几种机制可以扩展默认的 Conan 二进制模型

自定义设置

可以在 settings.yml 文件中添加新的设置或子设置，例如

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

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

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

class Pkg(ConanFile):
    # If we explicitly 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}

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

另请参阅

• 选项文档

• default_options 文档.

• 在配方中为依赖项定义选项没有强保证

设置 vs 选项 vs 配置

何时使用设置、选项或配置？

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

• 另一方面，选项 是特定于包的配置，会影响生成的包二进制文件。静态或共享库不是适用于所有包的设置。有些可以是仅头文件库，而其他包可以是纯数据或包可执行文件。例如，shared 是一个常见的选项（默认用于指定库是静态还是共享），但包可以定义和使用任何它们想要的选项。选项在包 conanfile.py 配方中定义，包括使用 options 和 default_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，而不是列出所有这些，例如 .*cmake 可以匹配包含“cmake”名称的任何配置（不建议这样做，请参阅下面的最佳实践）。

注意

最佳实践

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

交叉构建目标设置

self.settings_target 是 conanfile.py 属性，在交叉编译场景中对于“build”上下文中的 tool_requires 工具而言变得相关。当我们有一个像 CMake 这样的 tool_requires 时，包二进制文件与交叉编译将要定位的可能平台无关，对于所有不同的目标平台而言，它都是相同的 cmake 可执行文件。对于 Windows-X64 到 Linux-armv8 场景的 cmake/3.25.3 conanfile 配方，settings 将是

• self.settings：当前将运行 cmake/3.25.3 的设置。由于它是一个工具要求，它将在 Windows 机器上运行，因此 self.settings.os = Windows 和 self.settings.arch = x86_64。

• self.settings_build：如果需要构建此包，将构建当前构建机器的设置。这也是 Windows-x64 机器，因此 self.settings_build.os = Windows 和 self.settings_build.arch = x86_64。

• self.settings_target：当前应用程序结果将定位的设置。在这种情况下，它将是 self.settings_target.os = Linux 和 self.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")