generate()¶

此方法将在依赖图计算和安装后运行。这意味着它将在 conan install 命令之后运行，或者当在缓存中构建包时，它将在调用 build() 方法之前运行。

generate() 的目的是准备构建，生成必要的文件。这些文件通常是：

包含用于定位依赖项的信息文件，例如 xxxx-config.cmake CMake 配置脚本，或 xxxx.props Visual Studio 属性文件。
环境激活脚本，例如 conanbuild.bat 或 conanbuild.sh，它们定义了构建所需的所有必要环境变量。
工具链文件，例如 conan_toolchain.cmake，包含当前 Conan 设置和选项与构建系统特定语法之间的映射。CMakePresets.json 适用于使用现代版本的 CMake 用户。
通用构建信息，例如 conanbuild.conf 文件，其中可能包含一些工具链（如 autotools）要在 build() 方法中使用的信息。
特定的构建系统文件，例如 conanvcvars.bat，其中包含在使用 Microsoft 编译器编译时，某些构建系统（如 Ninja）所需的 Visual Studio vcvars.bat 调用。

其理念是 generate() 方法实现所有必要的逻辑，使得用户在 conan install 后手动构建非常直接，并且 build() 方法的逻辑也更简单。用户在其本地流程中产生的构建结果应与使用 conan create 在缓存中完成的构建结果完全相同，无需额外努力。

文件的生成发生在由当前布局定义的 generators_folder 中。

在许多情况下，generate() 方法可能不是必需的，声明 generators 属性可能就足够了。

from conan import ConanFile

class Pkg(ConanFile):
    generators = "CMakeDeps", "CMakeToolchain"

但是 generate() 方法可以显式实例化这些生成器，有条件地使用它们（例如在 Windows 中使用一个构建系统，在其他平台上使用另一个构建系统集成），自定义它们，或者提供完全自定义的生成。

from conan import ConanFile
from conan.tools.cmake import CMakeToolchain

class Pkg(ConanFile):

    def generate(self):
        tc = CMakeToolchain(self)
        # customize toolchain "tc"
        tc.generate()
        # Or provide your own custom logic

generate() 方法的当前工作目录将是当前布局中定义的 self.generators_folder。

对于自定义集成，将代码放在一个公共的 python_require 中是避免在多个配方中重复的好方法。

from conan import ConanFile
from conan.tools.cmake import CMakeToolchain

class Pkg(ConanFile):

    python_requires = "mygenerator/1.0"

    def generate(self):
        mygen = self.python_requires["mygenerator"].module.MyGenerator(self)
        # customize mygen behavior, like mygen.something= True
        mygen.generate()

如果需要从依赖项中收集或复制一些文件，也可以在 generate() 方法中进行，通过访问 self.dependencies。列出依赖项“mydep”的不同包含目录、库目录可以像这样实现：

from conan import ConanFile

class Pkg(ConanFile):

    def generate(self):
        info = self.dependencies["mydep"].cpp_info
        self.output.info("**includedirs:{}**".format(info.includedirs))
        self.output.info("**libdirs:{}**".format(info.libdirs))
        self.output.info("**libs:{}**".format(info.libs))

将 Windows 和 OSX 中的共享库复制到当前构建文件夹，可以这样做：

from conan import ConanFile

class Pkg(ConanFile):

    def generate(self):
        # NOTE: In most cases it is not necessary to copy the shared libraries
        # of dependencies to use them. Conan environment generators that create
        # environment scripts allow to use the shared dependencies without copying
        # them to the current location
        for dep in self.dependencies.values():
            # This code assumes dependencies will only have 1 libdir/bindir, if for some
            # reason they have more than one, it will fail. Use ``dep.cpp_info.libdirs``
            # and ``dep.cpp_info.bindirs`` lists for those cases.
            copy(self, "*.dylib", dep.cpp_info.libdir, self.build_folder)
            # In Windows, dlls are in the "bindir", not "libdir"
            copy(self, "*.dll", dep.cpp_info.bindir, self.build_folder)

注意

最佳实践

在 generate() 中将共享库复制到当前项目在大多数情况下不是必需的，也不应作为通用方法。相反，默认启用的 Conan 环境生成器会自动生成环境脚本，如 conanbuild.bat|.sh 或 conanrun.bat|.sh，其中包含必要的环境变量（PATH、LD_LIBRARY_PATH 等），以便在运行时正确地定位和使用依赖项的共享库。
访问依赖项的 self.dependencies["mydep"].package_folder 是可能的，但当依赖项“mydep”处于“可编辑”模式时，它将是 None。如果您计划使用可编辑包，请确保始终引用 cpp_info.xxxdirs。

另请参阅

请参阅关于在配方中准备从源代码构建的教程。

self.dependencies¶

Conan 配方通过 self.dependencies 属性访问其依赖项。此属性通常由诸如 CMakeDeps 或 MSBuildDeps 等生成器使用，以生成构建所需的文件。

本节介绍了 self.dependencies 属性，用户可以直接在配方中使用它，也可以间接使用它来创建自定义构建集成和生成器。

依赖项接口¶

可以使用以下语法访问当前配方的每个独立依赖项：

class Pkg(ConanFile):
    requires = "openssl/0.1"

    def generate(self):
        openssl = self.dependencies["openssl"]
        # access to members
        openssl.ref.version
        openssl.ref.revision # recipe revision
        openssl.options
        openssl.settings

        if "zlib" in self.dependencies:
            # do something

一些重要事项：

所有信息均为只读。任何修改依赖项信息的尝试都是错误的，并且随时可能引发错误，即使目前尚未引发。
也不可能通过此机制调用任何方法或尝试重用依赖项中的代码。
此信息在某些配方方法中不存在，仅在计算完完整的依赖图后才进行评估的方法中存在。它不会存在于 configure()、config_options、export()、export_source()、set_name()、set_version()、requirements()、build_requirements()、system_requirements()、source()、init()、layout() 中。在这些方法中尝试使用它随时可能引发错误。
目前，此信息应仅在 generate() 和 validate() 方法中使用。对于任何其他用途，请提交 Github 问题。

并非依赖项 conanfile 的所有字段都已公开，当前字段有：

package_folder: 依赖包二进制文件的文件夹位置
recipe_folder: 包含依赖项的 conanfile.py（及其他导出文件）的文件夹
recipe_metadata_folder: 包含依赖项可选配方元数据文件的文件夹
package_metadata_folder: 包含依赖项可选包元数据文件的文件夹
immutable_package_folder: 当 finalize() 方法存在时，包含不可变工件的文件夹
ref: 包含 name、version、user、channel 和 revision（配方修订版）的对象
pref: 包含 ref、package_id 和 revision（包修订版）的对象
buildenv_info: 包含构建所需环境信息的 Environment 对象
runenv_info: 包含运行应用程序所需环境信息的 Environment 对象
cpp_info: 依赖项的 includedirs、libdirs 等。
settings: 此依赖项的实际设置值
settings_build: 此依赖项的实际构建设置值
options: 此依赖项的实际选项值
context: 此依赖项的上下文（构建、主机）
conf_info: 此依赖项的配置信息，旨在应用于消费者。
dependencies: 此依赖项的传递依赖项
is_build_context: 如果 context == "build"，则返回 True。
conan_data: 来自依赖项 conandata.yml 文件的 conan_data 属性
license: 依赖项的 license 属性
description: 依赖项的 description 属性
homepage: 依赖项的 homepage 属性
url: 依赖项的 url 属性
package_type: 依赖项的 package_type
languages: 依赖项的 languages。
extension_properties: 依赖项的 extension_properties。应视为只读。

遍历依赖项¶

可以像字典一样遍历配方的所有依赖项。请注意，self.dependencies 包含所有当前依赖项，包括直接依赖项和传递依赖项。当前依赖项的每个对其有影响的上游依赖项都将在 self.dependencies 中有一个条目。

遍历依赖项可以这样做：

requires = "zlib/1.2.11", "poco/1.9.4"

def generate(self):
    for require, dependency in self.dependencies.items():
        self.output.info("Dependency is direct={}: {}".format(require.direct, dependency.ref))

将输出：

conanfile.py (hello/0.1): Dependency is direct=True: zlib/1.2.11
conanfile.py (hello/0.1): Dependency is direct=True: poco/1.9.4
conanfile.py (hello/0.1): Dependency is direct=False: pcre/8.44
conanfile.py (hello/0.1): Dependency is direct=False: expat/2.4.1
conanfile.py (hello/0.1): Dependency is direct=False: sqlite3/3.35.5
conanfile.py (hello/0.1): Dependency is direct=False: openssl/1.1.1k
conanfile.py (hello/0.1): Dependency is direct=False: bzip2/1.0.8

其中 require 字典键是一个“要求”，并且可以包含当前配方与依赖项之间关系的说明符。目前它们可以是：

require.direct: 布尔值，如果是直接依赖项则为 True，如果是传递依赖项则为 False。
require.build: 布尔值，如果它是构建上下文中的 build_require（例如 cmake），则为 True。
require.test: 布尔值，如果它是主机上下文中的 build_require（使用 self.test_requires() 定义），例如 gtest，则为 True。

dependency 字典值是上面描述的只读对象，用于访问依赖项属性。

self.dependencies 包含一些基于某些条件进行筛选的辅助方法：

self.dependencies.host: 将过滤掉 build=True 的要求，只保留常规依赖项，例如 zlib 或 poco。
self.dependencies.direct_host: 将过滤掉 build=True 或 direct=False 的要求。
self.dependencies.build: 将过滤掉 build=False 的要求，只保留构建上下文中的 tool_requires，例如 cmake。
self.dependencies.direct_build: 将过滤掉 build=False 或 direct=False 的要求。
self.dependencies.test: 将过滤掉 build=True 或 test=False 的要求，只保留主机上下文中的测试要求，例如 gtest。

它们可以以相同的方式使用。

requires = "zlib/1.2.11", "poco/1.9.4"

def generate(self):
    cmake = self.dependencies.direct_build["cmake"]
    for require, dependency in self.dependencies.build.items():
        # do something, only build deps here

依赖项 `cpp_info` 接口¶

cpp_info 接口被构建系统大量用于访问数据。此对象定义了全局和每个组件的属性，以访问包含文件夹等信息。

def generate(self):
    cpp_info = self.dependencies["mydep"].cpp_info
    cpp_info.includedirs
    cpp_info.libdirs

    cpp_info.components["mycomp"].includedirs
    cpp_info.components["mycomp"].libdirs

cppinfo 对象中声明的所有路径（例如 cpp_info.includedirs）都是绝对路径，并且无论依赖项是在缓存中还是可编辑包，都有效。