免责声明:我是CMakeLists.txt的新手,我有一个工作实现,并希望改进和增强它,问题描述如下:
如果我想要root/sub-directories/作为单独的子项目,可以使用CMakeLists.txts他们的文件夹中的个人编译我发现自己几乎复制粘贴CMakeLists.txt每个子目录几乎整个根文件.
我想知道是否有更好的方法来拥有一个主项目,然后是从主项目获得共享依赖项的子项目,并且可以在没有cmakeroot的情况下进行编译CMakeLists.txt.我的目录结构是;
CMakeLists.txt(根项目)
| __ sub_dir-1
| __ | __ CMakeLists.txt(子项目)
| __ sub_dir-2
| __ | __ CMakeLists.txt(子项目)
| __ sub_dir-3
| __ | __ CMakeLists.txt(子项目)
......
基本上,我希望能够:
cmake root/CMakeLists.txt,它创建了一个包含子项目的整个项目(我已经在子目录中使用单独的CMakeLists.txts实现了这个项目.cmake root/sub-dir/CMakeLists.txt并且只编译子项目,它本质上也找到了必要的依赖项,并且可能.cmake包含或包含它们root/CMakeLists.txt.接近这种结构的最佳方法是什么?
sub-dir/CMakeLists.txt太多了冗余的代码?感谢任何建议!谢谢.
Cra*_*ott 16
有一些策略可行,其中一些可以合并.
战略1:
如果您使用Unix MakefilesCMake生成器,那么只需make从与您要构建的子目录对应的构建输出目录调用,就可以在很大程度上完成您描述的内容.除非您正在构建的子目录(或其下的子目录)的目标需要,否则不会构建来自其他目录的目标.因此,当您从根目录运行CMake时,您仍然只构建所需的子目录.
优点:简单,无需更改CMakeLists.txt文件.
缺点:仅适用于Unix Makefiles生成器,需要CMake处理源树的所有部分是否要构建它们.
战略2:
正如@Emil在对你的问题的评论中所提到的,你可以简单地从构建输出目录的顶层构建你想要的特定目标.这假设您知道要构建的相关目标,或者换句话说,它需要您很好地了解哪些目标由哪些子目录提供.
优点:灵活,适用于任何CMake生成器,无需更改CMakeLists.txt文件.
缺点:需要了解每个子目录提供的内容,要求CMake处理源树的所有部分是否要构建它们.
战略3:
在顶级CMakeLists.txt文件中,您可以根据add_subdirectory()选项变量调用每个子目录.这将允许您单独打开或关闭每个子目录的包含,使您可以精确控制构建的内容.您可以构建所有内容,只需一个子目录或一组子目录(比您的要求更灵活,但可能有用).
有条件地包含带有选项变量的子目录通常会这样做:
option(BUILD_SUBDIR1 "Enable building subdir1" ON)
option(BUILD_SUBDIR2 "Enable building subdir2" ON)
if(BUILD_SUBDIR1)
add_subdirectory(subdir1)
endif()
if(BUILD_SUBDIR2)
add_subdirectory(subdir2)
endif()
Run Code Online (Sandbox Code Playgroud)
如果某些子目录依赖于其他子目录,那么是否添加子目录的逻辑将需要考虑(即实现选项之间的依赖关系).如果需要,应该不难做到.
优点:灵活地在一个构建中精确构建您想要的任何子目录集,CMake只需处理您感兴趣的子目录(为大型项目树节省时间并允许您跳过项目树中有问题的部分)并适用于任何CMake发电机.
缺点:如果要单独构建不同的子目录,则需要单独的构建目录.例如,您不能简单cd地使用构建输出目录结构的不同部分并从那里运行构建.您仍然只有一个源树,但是您有多个构建输出树.在实践中,这可能不是一个问题,取决于您最终希望能够做什么(我经常为给定的源树提供多个构建目录,但这通常用于Debug和Release构建而不是不同的CMake选项集).还需要了解子目录之间的依赖关系.需要对顶级CMakeLists.txt文件进行温和更改.
希望上述选项之一或其中的一些组合为您提供了一些如何最终实现您的目标的想法.我快速浏览了CMakeLists.txt你链接到的github项目中的顶层,看起来它已经使用了策略3中的选项,只是不能打开/关闭各个子目录.
| 归档时间: |
|
| 查看次数: |
18248 次 |
| 最近记录: |