创建conan包-打包现有二进制文件

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

1 Packaging Existing Binaries

There are specific scenarios in which it is necessary to create packages from existing binaries, for example from 3rd parties or binaries previously built by another process or team that are not using Conan. Under these circumstances building from sources is not what you want. You should package the local files in the following situations:
在某些特殊情况下，有必要从现有二进制文件创建软件包，例如从第三方或由其他未使用 Conan 的流程或团队构建的二进制文件。在这种情况下，从源代码构建软件包并不是您想要的。在以下情况下，应打包本地文件：

• When you cannot build the packages from sources (when only pre-built binaries are available).
• 无法从源代码构建软件包时（只有预构建的二进制文件可用）。
• When you are developing your package locally and you want to export the built artifacts to the local cache. As you don’t want to rebuild again (clean copy) your artifacts, you don’t want to call conan create. This method will keep your build cache if you are using an IDE or calling locally to the conan build command.
• 当您在本地开发软件包，并希望将构建的工件导出到本地缓存时。由于您不想再次重建（清空副本）您的工件，所以您不想调用 conan create。如果您使用集成开发环境或在本地调用 conan build 命令，此方法将保留您的构建缓存。

1.1 Packaging Pre-built Binaries

Running the build() method, when the files you want to package are local, results in no added value as the files copied from the user folder cannot be reproduced. For this scenario, run conan export-pkg command directly.
当要打包的文件是本地文件时，运行 build() 方法不会带来任何附加值，因为从用户文件夹复制的文件无法再现。在这种情况下，请直接运行 conan export-pkg 命令。

A Conan recipe is still required, but is very simple and will only include the package meta information. A basic recipe can be created with the conan new command:
Conan 配方仍是必需的，但非常简单，只包含软件包元信息。可以使用 conan new 命令创建基本配方：

$ conan new hello/0.1 --bare

This will create and store the following package recipe in the local cache:
这将在本地缓存中创建并存储以下软件包配方：

class HelloConan(ConanFile):
    name = "hello"
    version = "0.1"
    settings = "os", "compiler", "build_type", "arch"

    def package(self):
        self.copy("*")

    def package_info(self):
        self.cpp_info.libs = self.collect_libs()

The provided package_info() method scans the package files to provide end-users with the name of the libraries to link to. This method can be further customized to provide additional build flags (typically dependent on the settings). The default package_info() applies as follows: it defines headers in the “include” folder, libraries in the “lib” folder, and binaries in the “bin” folder. A different package layout can be defined in the package_info() method.
所提供的 package_info() 方法会扫描软件包文件，为最终用户提供要链接的库名称。该方法可进一步定制，以提供额外的构建标志（通常取决于设置）。默认的 package_info() 应用如下：在 "include "文件夹中定义头文件，在 "lib "文件夹中定义库，在 "bin "文件夹中定义二进制文件。可以在 package_info() 方法中定义不同的软件包布局。

This package recipe can be also extended to provide support for more configurations (for example, adding options: shared/static, or using different settings), adding dependencies (requires), and more.
该软件包配方还可以扩展，以支持更多配置（例如，添加选项：共享/静态，或使用不同的设置）、添加依赖项（要求）等。

Based on the above, we can assume that our current directory contains a lib folder with a number binaries for this “hello” library libhello.a, compatible for example with Windows MinGW (gcc) version 4.9:
根据上述情况，我们可以假设当前目录下有一个 lib 文件夹，其中包含 "hello "库 libhello.a 的若干二进制文件，例如与 Windows MinGW (gcc) 4.9 版本兼容：

$ conan export-pkg . hello/0.1@myuser/testing  -s os=Windows -s compiler=gcc -s compiler.version=4.9 ...

Having a test_package folder is still highly recommended for testing the package locally before upload. As we don’t want to build the package from the sources, the flow would be:
我们仍然强烈建议在上传软件包前在本地测试 test_package 文件夹。由于我们不想从源代码构建软件包，因此流程如下

$ conan new hello/0.1 --bare --test
# customize test_package project
# customize package recipe if necessary
$ cd my/path/to/binaries
$ conan export-pkg PATH/TO/conanfile.py hello/0.1@myuser/testing  -s os=Windows -s compiler=gcc -s compiler.version=4.9 ...
$ conan test PATH/TO/test_package/conanfile.py hello/0.1@myuser/testing -s os=Windows -s compiler=gcc -s ...

The last two steps can be repeated for any number of configurations.
最后两个步骤可以重复进行，以获得任意数量的配置。

1.2 Downloading and Packaging Pre-built Binaries

In this scenario, creating a complete Conan recipe, with the detailed retrieval of the binaries could be the preferred method, because it is reproducible, and the original binaries might be traced. Follow our sample recipe for this purpose:
在这种情况下，创建一个完整的conan recipe并详细检索二进制文件可能是首选方法，因为这种方法具有可重复性，而且可以追踪到原始的二进制文件。为此，请参考我们的示例配方：

class HelloConan(ConanFile):
    name = "hello"
    version = "0.1"
    settings = "os", "compiler", "build_type", "arch"

    def build(self):
        if self.settings.os == "Windows" and self.settings.compiler == "Visual Studio":
            url = ("https://<someurl>/downloads/hello_binary%s_%s.zip"
                   % (str(self.settings.compiler.version), str(self.settings.build_type)))
        elif ...:
            url = ...
        else:
            raise Exception("Binary does not exist for these settings")
        tools.get(url)

    def package(self):
        self.copy("*") # assume package as-is, but you can also copy specific files or rearrange

    def package_info(self):  # still very useful for package consumers
        self.cpp_info.libs = ["hello"]

Typically, pre-compiled binaries come for different configurations, so the only task that the build() method has to implement is to map the settings to the different URLs.
通常情况下，预编译的二进制文件会有不同的配置，因此 build() 方法需要执行的唯一任务就是将设置映射到不同的 URL。

Note

• This is a standard Conan package even if the binaries are being retrieved from elsewhere. The recommended approach is to use conan create, and include a small consuming project in addition to the above recipe, to test locally and then proceed to upload the Conan package with the binaries to the Conan remote with conan upload.
• 即使二进制文件是从其他地方获取的，这也是一个标准的 Conan 软件包。建议的方法是使用 conan create，并在上述配方中加入一个小型消耗项目，在本地进行测试，然后使用 conan upload 将包含二进制文件的 Conan 软件包上传到远端 Conan。
• The same building policies apply. Having a recipe fails if no Conan packages are created, and the --build argument is not defined. A typical approach for this kind of packages could be to define a build_policy=“missing”, especially if the URLs are also under the team control. If they are external (on the internet), it could be better to create the packages and store them on your own Conan server, so that the builds do not rely on third party URL being available.
• 同样的构建策略也适用。如果没有创建conan软件包，也没有定义 --build 参数，配方就会失效。对于这类软件包，典型的方法是定义 build_policy="missing"，尤其是当 URL 也在团队控制之下时。如果它们是外部的（在互联网上），最好是创建软件包并将其存储在自己的 Conan 服务器上，这样编译就不会依赖于第三方 URL 的可用性。