conanfile.py-Methods-package_info()

本文是基于对conan官方文档package_info()翻译而来， 更详细的信息可以去查阅conan官方文档。

1 cpp_info

Each package has to specify certain build information for its consumers. This can be done in the cpp_info attribute within the package_info() method.
每个软件包都必须为其用户指定特定的构建信息。这可以通过 package_info() 方法中的 cpp_info 属性来实现。

The cpp_info attribute has the following properties you can assign/append to:
cpp_info 属性具有以下特性，您可以对其进行指定/附加：

self.cpp_info.names["generator_name"] = "<PKG_NAME>"
self.cpp_info.includedirs = ['include']  # Ordered list of include paths
self.cpp_info.libs = []  # The libs to link against
self.cpp_info.system_libs = []  # System libs to link against
self.cpp_info.libdirs = ['lib']  # Directories where libraries can be found
self.cpp_info.resdirs = ['res']  # Directories where resources, data, etc. can be found
self.cpp_info.bindirs = ['bin']  # Directories where executables and shared libs can be found
self.cpp_info.srcdirs = []  # Directories where sources can be found (debugging, reusing sources)
self.cpp_info.build_modules = {
   }  # Build system utility module files
self.cpp_info.defines = []  # preprocessor definitions
self.cpp_info.cflags = []  # pure C flags
self.cpp_info.cxxflags = []  # C++ compilation flags
self.cpp_info.sharedlinkflags = []  # linker flags
self.cpp_info.exelinkflags = []  # linker flags
self.cpp_info.components  # Dictionary with the different components a package may have
self.cpp_info.requires = None  # List of components from requirements

• names: Alternative name(s) for the package to be used by generators.
• names： 生成器使用的软件包替代名称。
• includedirs: List of relative paths (starting from the package root) of directories where headers can be found. By default it is initialized to ['include'], and it is rarely changed.
• includedirs： 头文件所在目录的相对路径列表（从软件包根目录开始）。默认情况下，它被初始化为['include']，并且很少更改。
• libs: Ordered list of libs the client should link against. Empty by default, it is common that different configurations produce different library names. For example:
• libs： 客户端应链接的库的有序列表。默认情况下为空，不同的配置通常会产生不同的库名。例如

def package_info(self):
    if not self.settings.os == "Windows":
        self.cpp_info.libs = ["zmq-static"] if self.options.static else ["zmq"]
    else:
        ...

• libdirs: List of relative paths (starting from the package root) of directories in which to find library object binaries (*.lib, *.a, *.so, *.dylib). By default it is initialized to ['lib'], and it is rarely changed.
• libdirs： 查找库对象二进制文件（*.lib、*.a、*.so、*.dylib）的相对路径列表（从软件包根目录开始）。默认情况下，它被初始化为 ['lib']，并且很少更改。
• resdirs: List of relative paths (starting from the package root) of directories in which to find resource files (images, xml, etc). By default it is initialized to ['res'], and it is rarely changed.
• resdirs： 用于查找资源文件（images、xml 等）的目录的相对路径列表（从软件包根目录开始）。默认情况下初始化为['res']，很少更改。
• bindirs: List of relative paths (starting from the package root) of directories in which to find library runtime binaries (like Windows .dlls). By default it is initialized to ['bin'], and it is rarely changed.
• bindirs： 查找运行库二进制文件（如 Windows .dlls）目录的相对路径列表（从软件包根目录开始）。默认情况下初始化为['bin']，很少更改。
• srcdirs: List of relative paths (starting from the package root) of directories in which to find sources (like .c, .cpp). By default it is empty. It might be used to store sources (for later debugging of packages, or to reuse those sources building them in other packages too).
• srcdirs： 查找源代码（如 .c、.cpp）目录的相对路径列表（从软件包根目录开始）。默认为空。它可用于存储源代码（以便日后调试软件包，或在其他软件包中重复使用这些源代码）。
• build_modules: Dictionary of lists per generator containing relative paths to build system related utility module files created by the package. Used by CMake generators to include .cmake files with functions for consumers. e.g: self.cpp_info.build_modules["cmake_find_package"].append("cmake/myfunctions.cmake"). Those files will be included automatically in cmake/cmake_multi generators when using conan_basic_setup() and will be automatically added in cmake_find_package/cmake_find_package_multi generators when find_package() is used.
• build_modules： 每个生成器的列表字典，包含软件包创建的与构建系统相关的实用程序模块文件的相对路径。例如：self.cpp_info.build_modules["cmake_find_package"].append("cmake/myfunctions.cmake")。使用 conan_basic_setup() 时，这些文件将自动包含在 cmake/cmake_multi 生成器中；使用 find_package() 时，这些文件将自动添加到 cmake_find_package/cmake_find_package_multi 生成器中。
• defines: Ordered list of preprocessor directives. It is common that the consumers have to specify some sort of defines in some cases, so that including the library headers matches the binaries.
• defines： 预处理器指令的有序列表。在某些情况下，用户通常需要指定某种定义，以便包含的库头文件与二进制文件相匹配。
• system_libs: Ordered list of system libs the consumer should link against. Empty by default.
• system_libs： 用户应链接的系统库有序列表。默认为空。
• cflags, cxxflags, sharedlinkflags, exelinkflags: List of flags that the consumer should activate for proper behavior. Usage of C++11 could be configured here, for example, although it is true that the consumer may want to do some flag processing to check if different dependencies are setting incompatible flags (c++11 after c++14).
• cflags、cxxflags、sharedlinkflags、exelinkflags： 用户应激活才能正常运行的标志列表。例如，可以在此配置 C++11 的使用，不过用户可能确实需要进行一些标志处理，以检查不同的依赖程序是否设置了不兼容的标志（c++11 后为 c++14）。

if self.options.static:
    if self.settings.compiler == "Visual Studio":
        self.cpp_info.libs.append("ws2_32")
    self.cpp_info.defines = ["ZMQ_STATIC"]

    if not self.settings.os == "Windows":
        self.cpp_info.cxxflags = ["-pthread"]

Note that due to the way that some build systems, like CMake, manage forward and back slashes, it might be more robust passing flags for Visual Studio compiler with dash instead. Using "/NODEFAULTLIB:MSVCRT", for example, might fail when using CMake targets mode, so the following is preferred and works both in the global and targets mode of CMake:
请注意，由于某些编译系统（如 CMake）管理正斜线和反斜线的方式，为 Visual Studio 编译器传递标记时使用破折号可能更稳健。例如，使用"/NODEFAULTLIB:MSVCRT "可能会在使用 CMake 目标模式时失败，因此以下方法更为可取，并且在 CMake 的全局和目标模式下均可使用：

def package_info(self):
    self.cpp_info.exelinkflags = ["-NODEFAULTLIB:MSVCRT",
                                  "-DEFAULTLIB:LIBCMT"]

• components: [Experimental] Dictionary with names as keys and a component object as value to model the different components a package may have: libraries, executables… Read more about this feature at Using Components.
• components： [试验性] 以名称为键、组件对象为值的字典，用于模拟软件包可能具有的不同组件：库、可执行文件… 在 使用组件 了解有关此功能的更多信息。
• requires: [Experimental] List of components from the requirements this package (and its consumers) should link with. It will be used by generators that add support for components features (Using Components).
• requires： [实验] 本软件包（及其消费者）应链接的需求中的组件列表。它将用于为组件功能添加支持的生成器（使用组件）。

If your recipe has requirements, you can access to the information stored in the cpp_info of your requirements using the deps_cpp_info object:
如果配方中包含需求，则可以使用 deps_cpp_info 对象访问需求的 cpp_info 中存储的信息：

class OtherConan(ConanFile):
    name = "OtherLib"
    version = "1.0"
    requires = "mylib/1.6.0@conan/stable"

    def build(self):
        self.output.warn(self.deps_cpp_info["mylib"].libdirs)

Please take into account that defining self.cpp_info.bindirs directories, does not have any effect on system paths, PATH environment variable, nor will be directly accessible by consumers. self.cpp_info information is translated to build-systems information via generators, for example for CMake, it will be a variable in conanbuildinfo.cmake. If you want a package to make accessible its executables to its consumers, you have to specify it with self.env_info as described in env_info.
请注意，定义 self.cpp_info.bindirs 目录不会对系统路径、PATH 环境变量产生任何影响，也不会被用户直接访问。self.cpp_info 信息会通过生成器转化为联编系统信息，例如对于 CMake 而言，它会成为 conanbuildinfo.cmake 中的一个变量。如果希望软件包向其用户提供可执行文件，则必须按照 env_info 中的说明使用 self.env_info 来指定。

2 env_info

This is a deprecated feature. Please refer to the Migration Guidelines to find the feature that replaced this one.
这是一个已废弃的功能。请参阅 “迁移指南”，查找取代此功能的功能。

Each package can also define some environment variables that the package needs to be reused. It’s specially useful for installer packages, to set the path with the “bin” folder of the packaged application. This can be done in the env_info attribute within the package_info() method.
每个软件包还可以定义一些需要重复使用的环境变量。对于安装包来说，设置打包应用程序的 "bin "文件夹路径特别有用。这可以在 package_info() 方法中的 env_info 属性中完成。

self.env_info.path.append("ANOTHER VALUE") # Append "ANOTHER VALUE" to the path variable
self.env_info.othervar = "OTHER VALUE" # Assign "OTHER VALUE" to the othervar variable
self.env_info.thirdvar.append("some value") # Every variable can be set or appended a new value

One of the most typical usages for the PATH environment variable, would be to add the current binary package directories to the path, so consumers can use those executables easily:
PATH 环境变量最典型的用途之一，就是将当前的二进制软件包目录添加到路径中，以便用户可以轻松使用这些可执行文件：

# assuming the binaries are in the "bin" subfolder
self.env_info.PATH.append(os.path.join(self.package_folder, "bin"))

The virtualenv generator will use the self.env_info variables to prepare a script to activate/deactivate a virtual environment. However, this could be directly done using the virtualrunenv generator.
virtualenv 生成器将使用 self.env_info 变量来编写脚本，以activate/deactivate虚拟环境。不过，这也可以直接使用 virtualrunenv 生成器来完成。

They will be automatically applied before calling the consumer conanfile.py methods source(), build(), package() and imports().
它们将在调用用户 conanfile.py 方法 source()、 build()、 package() 和 imports(). 前自动应用。

If your recipe has requirements, you can access to your requirements env_info as well using the deps_env_info object.
如果您的配方有需求，您也可以使用 deps_env_info 对象访问需求 env_info。

class OtherConan(ConanFile):
    name = "OtherLib"
    version = "1.0"
    requires = "mylib/1.6.0@conan/stable"

    def build(self):
        self.output.warn(self.deps_env_info["mylib"].othervar)

3 user_info

This is a deprecated feature. Please refer to the Migration Guidelines to find the feature that replaced this one.
这是一个已废弃的功能。请参阅 Migration Guidelines，查找取代此功能的功能。

If you need to declare custom variables not related with C/C++ (cpp_info) and the variables are not environment variables (env_info), you can use the self.user_info object.
如果需要声明与 C/C++ 无关的自定义变量 (cpp_info)，且变量不是环境变量 (env_info)，则可以使用 self.user_info 对象。

Currently only the cmake, cmake_multi and txt generators supports user_info variables.
目前只有 cmake、cmake_multi 和 txt 生成器支持 user_info 变量。

class MyLibConan(ConanFile):
    name = "mylib"
    version = "1.6.0"

    # ...

    def package_info(self):
        self.user_info.var1 = 2

For the example above, in the cmake and cmake_multi generators, a variable CONAN_USER_MYLIB_var1 will be declared. If your recipe has requirements, you can access to your requirements user_info using the deps_user_info object.
例如，在 cmake 和 cmake_multi 生成器中，将声明一个变量 CONAN_USER_MYLIB_var1。如果您的配方有需求，您可以使用 deps_user_info 对象访问您的需求 user_info。

class OtherConan(ConanFile):
    name = "otherlib"
    version = "1.0"
    requires = "mylib/1.6.0@conan/stable"

    def build(self):
        self.out.warn(self.deps_user_info["mylib"].var1)

Both env_info and user_info objects store information in a “key <-> value” form and the values are always considered strings. This is done for serialization purposes to conanbuildinfo.txt files and to avoid the deserialization of complex structures. It is up to the consumer to convert the string to the expected type:
env_info 和 user_info 对象都以 "key <-> value "的形式存储信息，而值始终被视为字符串。这样做是为了序列化到 conanbuildinfo.txt 文件，并避免反序列化复杂结构。用户可自行将字符串转换为预期类型：

# In a dependency
self.user_info.jars="jar1.jar, jar2.jar, jar3.jar"  # Use a string, not a list
...

# In the dependent conanfile
jars = self.deps_user_info["pkg"].jars
jar_list = jars.replace(" ", "").split(",")