build()

build() 方法用于定义软件包的源码构建。 实际上，这意味着调用一些构建系统，可以通过显式方式完成，也可以使用 Conan 提供的任何构建助手。

from conan.tools.cmake import CMake

class Pkg(ConanFile):

    def build(self):
        # Either using some of the Conan built-in helpers
        cmake = CMake(self)
        cmake.configure()  # equivalent to self.run("cmake . <other args>")
        cmake.build() # equivalent to self.run("cmake --build . <other args>")
        cmake.test()  # equivalent to self.run("cmake --target=RUN_TESTS")

        # Or it could run your own build system or scripts
        self.run("mybuildsystem . --configure")
        self.run("mybuildsystem . --build")

有关现有内置构建系统集成的更多信息，请访问 Recipe 工具。

build() 方法应尽可能简单，只需封装开发人员以最简单方式执行的命令行调用。 generate() 方法负责准备构建，创建工具链文件、CMake 预设或任何其他必要的文件，以便开发人员可以轻松地手动调用构建系统。 这使得与 IDE 的集成更好，并改善了开发人员的体验。 结果是，实际上 build() 方法应该相对简单。

build() 方法对于每个唯一的配置运行一次，因此如果有一些源码操作（如应用补丁）是根据不同的配置有条件地完成的，它们也可以在实际构建之前的 build() 方法中应用。 重要的是要注意，在这种情况下，no_copy_source 属性不能设置为 True。

build() 方法是构建和运行单元测试的正确位置，在打包之前，如果这些测试失败，则会引发错误，中断流程，甚至不会打包最终的二进制文件。 如果定义了 tools.build:skip_test 配置，内置助手将跳过单元测试。 对于自定义集成，期望该方法检查此 conf 值，以便跳过构建和运行测试，这对于某些 CI 场景可能很有用。

在交叉编译场景中运行测试： 在某些情况下，您可能想要构建测试但无法运行它们，例如在交叉编译场景中。 对于这些罕见的情况，您可以使用 conan.tools.build.can_run 工具，如下所示

...

def build(self):
    cmake = CMake(self)
    cmake.configure()
    cmake.build()
    if can_run(self):
        cmake.test()

注意

最佳实践

• build() 方法应尽可能简单，准备构建的繁重工作应在 generate() 方法中进行，以实现良好的开发人员体验，该体验可以使用 conan install . 轻松地在本地构建，并直接调用构建系统或打开他们的 IDE。

另请参阅

请按照 关于构建软件包的教程 了解有关从源码构建的更多信息。