我正在开发一个跨平台的项目,该项目使用了大量的第三方库(目前有22个并计算在内,我预计这个数字会显着增加)。我的项目是基于CMake的,并保持ThirdParty /目录的组织如下:
第三方/ $ LIBNAME /包含/
第三方/ $ LIBNAME / LIB / $平台/ $ buildtype /
我的CMakeLists.txt有逻辑来确定$ platform(mac-i386,mac-ia64,win32-i386等)和$ buildtype(调试/发布)的适当值。
难以让每个平台保持这些库的最新状态。目前我手动执行此操作 - 当我更新一个库时,我会为每个平台重建它。但这是一场噩梦,增加一个新平台是两天的事情。
如果第三方库本身是基于CMake的,那么这将很容易实现自动化,但它们使用从CMake到autoconf的所有内容,再到手工制作Makefile的自定义解决方案。它们之间没有一致性,并且都需要在构建平台方面跳过各种环节(特别是关于32位和64位版本)。
是否有任何工具(或CMake扩展程序)可以更容易管理?例如,在CMake和autoconf之间是否有任何合理的共同点?
理想的解决方案将为我提供一个命令来构建需要为给定平台重建的所有内容(交叉编译不是必需的,因为我可以访问所有必需的平台),但任何逐步使我生活更轻松的事情都将是赞赏。
答案 0 :(得分: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源代码从源代码树复制到构建树中,运行configure步骤(在cd进入复制目录后),然后在配置目录上运行make。最后,zlib的构建版本安装在当前构建目录中,位于名为zlib-build的子目录中。
您可以随意调整设置,配置和构建步骤 - 例如,zlib 1.2.4不希望“配置”在源外运行。
对于自定义设置,您可以跳过CONFIGURE步骤并运行build命令(例如)。这需要最新版本的CMake才能工作(2.8 +)。