【问题标题】:Framework for building and managing third-party libraries构建和管理第三方库的框架
【发布时间】:2010-08-07 16:46:52
【问题描述】:

我正在开发一个跨平台项目,该项目使用大量第三方库(目前有 22 个并且还在增加,我预计这个数字会显着增加)。我的项目是基于 CMake 的,并保持 ThirdParty/ 目录的组织方式如下:

第三方/$libname/include/
第三方/$libname/lib/$platform/$buildtype/

我的 CMakeLists.txt 具有确定 $platform(mac-i386、mac-ia64、win32-i386 等)和 $buildtype(调试/发布)的适当值的逻辑。

在为每个平台保持这些库是最新的方面出现了困难。目前我正在手动执行此操作 - 当我更新一个库时,我会为每个平台重建它。但这是一场噩梦,添加新平台需要两天时间。

如果第三方库本身是基于 CMake 的,这将很容易实现自动化,但它们使用从 CMake 到 autoconf 到自定义解决方案再到手动生成文件的所有内容。它们之间没有一致性,并且都需要在构建平台方面跳过各种箍(尤其是在 32 位和 64 位构建方面)。

是否有任何工具(或 CMake 扩展)可以使其更易于管理?例如,CMake 和 autoconf 之间是否有任何合理的共同点?

理想的解决方案会给我一个命令来构建需要为给定平台重建的所有内容(不需要交叉编译,因为我可以访问所有必要的平台),但是任何让我的生活更轻松的东西都是赞赏。

【问题讨论】:

    标签: build build-process compilation cmake autoconf


    【解决方案1】:

    您可能可以使用ExternalProject

    创建自定义目标以在外部树中构建项目。 “ExternalProject_Add”函数创建一个自定义目标来驱动外部项目的下载、更新/修补、配置、构建、安装和测试步骤。

    如果您的项目文件层次结构中已经有源代码,那么您可以使用类似这样的东西(对于 zlib):

    include(ExternalProject)
    ExternalProject_Add(zlib URL ${CMAKE_CURRENT_SOURCE_DIR}/zlib-1.2.4/
        CONFIGURE_COMMAND cd <SOURCE_DIR> && ./configure --prefix=${CMAKE_CURRENT_BINARY_DIR}/zlib-build
        BUILD_IN_SOURCE 1
        BUILD_COMMAND make)
    

    这会将 zlib 源代码从源代码树复制到构建树中,运行配置步骤(在 cd 进入复制的目录之后),然后在配置的目录上运行 make。最后,zlib 的构建版本被安装到当前构建目录的一个名为 zlib-build 的子目录中。

    您可以随心所欲地调整设置、配置和构建步骤 - 例如,zlib 1.2.4 不喜欢“配置”在源代码之外运行。

    对于自定义设置,您可以跳过配置步骤,只运行构建命令(例如)。这需要使用最新版本的 CMake (2.8+)。

    【讨论】:

    • 哇。这看起来正是我正在寻找的。谢谢!
    猜你喜欢
    • 2019-03-17
    • 1970-01-01
    • 2018-12-01
    • 2013-10-20
    • 1970-01-01
    • 2013-04-09
    • 1970-01-01
    • 2015-01-27
    • 1970-01-01
    相关资源
    最近更新 更多