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")

有关现有内置构建系统集成的更多信息,请访问 配方工具

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。

另请参阅

请参阅关于构建软件包的教程,了解有关从源代码构建的更多信息。