我有一个大型的代码库,它构建了几十个库和几个可执行文件.
代码库按层次分解,并且几乎每个级别都构建了库.
我已经完成并在每个目录中放置了一个CMakeLists.txt文件来构建每个库.
在每个CMakeLists.txt中,我使用了"project(xxx)"指令.这为我定义了PROJECT_NAME,PROJECT_SOURCE_DIR和PROJECT_BINARY_DIR变量,我明智地使用了这些变量.
然而,其中一个团队对这种方法不满意,因为他找不到任何其他人做过这个的真实世界的例子.他经常引用KitWare示例不使用这种方法,因此我们也不应该这样做.
他提倡的替代方法是在每个makefile中设置这些变量,这看起来就像"项目"给你的那样.
我真的看不出他的观点,并且在说服他的方面没有取得什么进展.任何人都可以用这种方式阐明使用项目指令的缺点.
我抛弃你的集体智慧？
Mar*_*oot 12
首先,它使您能够使用<projectName>_BINARY_DIR和<projectName>_SOURCE_DIR,但这不是主要优势.如果你给CMake一个项目名称,那么它将为他们自己的目录中的每个子项目生成构建目标.这意味着无论您使用的是GNU Make,Eclipse CDT,XCode还是任何其他受支持的生成器,您都可以单独构建子项目.例如,使用GNU Make,每个子项目都有自己的完整构建系统.
您可以通过PROJECT_NAME以及根项目名称访问当前项目名称CMAKE_PROJECT_NAME.
编辑:我刚刚意识到以下将是任何构建目标的标准CMake行为,无论它们是否是项目.我会在这里保留一般信息,但它与答案无关:
假设我有一个C++库,我可以生成三个二进制可执行文件; Main和tests/test1,和examples/ex1.我可以在我使用ALL目标调用CMake的目录中运行make,运行make ex1,或者我可以将目录更改为examples/并make从该目录构建示例.这将构建所有依赖项目和库,即使它们位于目录结构中的其他位置但不会构建Main或者tests/test1它们所依赖的任何库也不构建examples/ex1.如果我然后从主目录运行make,它将不会重建任何examples/ex1依赖的库,除非它们的源已更改.
| 归档时间： |
|
| 查看次数： |
5951 次 |
| 最近记录： |