generate()¶

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

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

包含定位依赖项的信息的文件，例如 xxxx-config.cmake CMake 配置脚本，或 xxxx.props Visual Studio 属性文件。
环境激活脚本，例如 conanbuild.bat 或 conanbuild.sh，它们定义了构建所需的所有必要的环境变量。
工具链文件，例如 conan_toolchain.cmake，它包含当前 Conan 设置和选项与构建系统特定语法之间的映射。使用现代版本的 CMake 用户的 CMakePresets.json。
通用构建信息，例如 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 中，将是避免在多个 recipe 中重复的好方法

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” 的不同 include 目录，lib 目录可以像这样实现

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 环境生成器将自动生成环境脚本，例如带有必要环境变量（PATH、LD_LIBRARY_PATH 等）的 conanbuild.bat|.sh 或 conanrun.bat|.sh，以便在运行时正确地定位和使用依赖项的共享库。
访问依赖项 self.dependencies["mydep"].package_folder 是可能的，但是当依赖项 “mydep” 处于 “editable” 模式时，它将是 None。如果您计划使用可编辑的包，请确保始终引用 cpp_info.xxxdirs。

另请参阅

请遵循关于在 recipe 中准备从源代码构建的教程。

self.dependencies¶

Conan recipe 通过 self.dependencies 属性访问它们的依赖项。此属性通常被 CMakeDeps 或 MSBuildDeps 等生成器用来生成构建所需的文件。

本节记录 self.dependencies 属性，因为它可能被用户直接在 recipe 中使用，或者间接地用于创建自定义构建集成和生成器。

依赖接口¶

可以使用以下语法访问当前 recipe 的每个单独的依赖项

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

一些重要的点

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

并非依赖项 conanfile 的所有字段都暴露出来，当前的字段是

package_folder: 依赖项包二进制文件的文件夹位置
recipe_folder: 包含依赖项的 conanfile.py（和其他导出的文件）的文件夹
recipe_metadata_folder: 包含依赖项的可选 recipe 元数据文件的文件夹
package_metadata_folder: 包含依赖项的可选包元数据文件的文件夹
immutable_package_folder: 当存在 finalize() 方法时，包含不可变工件的文件夹
ref: 一个包含 name、version、user、channel 和 revision (recipe revision) 的对象
pref: 一个包含 ref、package_id 和 revision (package revision) 的对象
buildenv_info: 包含构建所需的环境信息的 Environment 对象
runenv_info: 包含运行应用程序所需的环境信息的 Environment 对象
cpp_info: 依赖项的 includedirs、libdirs 等。
settings: 此依赖项的实际设置值
settings_build: 此依赖项的实际构建设置值
options: 此依赖项的实际选项值
context: 此依赖项的上下文 (build, host)
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 字典键是“requirement”（需求），可以包含当前配方与依赖项之间关系的说明符。目前，它们可以是：

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

dependency 字典值是上述只读对象，可以访问依赖项属性。

self.dependencies 包含一些辅助方法，可以根据某些标准进行过滤：

self.dependencies.host：将过滤掉 build=True 的 requires，留下像 zlib 或 poco 这样的常规依赖项。
self.dependencies.direct_host：将过滤掉 build=True 或 direct=False 的 requires。
self.dependencies.build：将过滤掉 build=False 的 requires，只留下构建上下文中的 tool_requires，例如 cmake。
self.dependencies.direct_build：将过滤掉 build=False 或 direct=False 的 requires。
self.dependencies.test：将过滤掉 build=True 或 test=False 的 requires，只留下主机上下文中的测试需求，例如 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）都是绝对路径，并且无论依赖项是在缓存中还是在可编辑包中，都可以工作。