我正在尝试设置我的项目以使用 CMake 正确编译。
我的目录如下所示：
root
|- bin
| |- // Where I want to build CMake from - using 'cmake ..'
|- build
| |-
|- include
| |- database
| | |- database.h
|- src
|- database
| |- database.cpp
|- main
|- main.cpp
随着我的项目变大，我的子目录肯定会增长，并且我认为 CMake 可能是一个学习的好主意。目前我只能让 CMake 在 src/ 中没有子目录的情况下工作。然而，我确实希望这个项目能够发展成许多子目录。
我需要多个吗CMakeLists.txt每个目录中都有 .cpp 文件吗？有人能指出我正确的方向吗？
谢谢你！
我会推荐你去本文 https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/深入讨论两种主要方法，但是您可以通过几种方法来构建这样的项目。
- One
CMakeLists.txt文件位于顶层，列出了所有不同子目录中的所有源文件。您通常只会在非常简单的项目中看到这一点。
- One
CMakeLists.txt每个目录中的文件，每个目录都是由其父目录使用引入的add_subdirectory()。这种方法很常见，通常也是推荐的方法。
- One
CMakeLists.txt文件位于顶层，每个子目录都有自己的文件，其中列出了自己的源文件和目标。顶层CMakeLists.txtfile 引入子目录 filesinclude()。此方法不太常见，但在某些情况下比其他两种方法具有优势。但一般来说这不是推荐的方法。
每个都有其优点和缺点。只有一个顶级CMakeLists.txt仅当文件和子目录很少时才推荐使用 file。一旦项目增长，将所有内容都保留在顶层可能会变得太多，并导致结果CMakeLists.txt文件更难遵循。它还有一个缺点，即文件添加或删除的更改不限于特定目录。这看起来似乎没什么大不了的，但如果多个人正在处理一个项目，并且您想轻松查看其他人的更改影响了项目的哪些部分（例如在 git 历史记录中），那就更难了。如果您都添加/删除文件，从而都更改顶层，则尤其如此CMakeLists.txt文件并有可能发生冲突。
一旦项目规模变得不小，大多数人都会选择添加一个CMakeLists.txt每个子目录中的文件并使用add_subdirectory()把他们聚集在一起。 @TheQuantumPhysicist 的回答给出了一个很好的例子，说明了这如何有用，所以我不会在这里重复大部分细节。这种结构使您能够轻松打开/关闭构建树的整个部分，但更重要的是，它为每个子目录提供了自己的变量范围。如果您想在源树的一部分中设置变量等，但这些更改在另一部分中不可见，那么这一点可能很重要。每个子目录也有自己的目录属性范围。这些单独的作用域使您可以更轻松地将编译器标志和其他临时值等内容应用于复杂目录结构的一部分。
第三种选择 一级CMakeLists.txt文件，每个子目录提供一个由以下命令引入的文件include()不太常见，但它与使用一种有相似之处CMakeLists.txt每个子目录中的文件。两者都将目录中文件的详细信息本地化到CMakeLists.txt或该目录中其他类似名称的文件。因此，在版本控制历史等中，更改变得更容易合并和理解。当使用 CMake 3.12 或更早版本时，第三种方法允许的一件事是你可以使用第二种方法不允许的事情target_link_libraries()使用时更自由一点target_sources()指定每个子目录中的源文件。本答案顶部链接的文章详细介绍了原因target_sources()可以是有利的。如果您的最低 CMake 版本是 3.13 或更高版本，则第三种方法不如第二种，通常应避免。
最后，我建议您不要养成将构建树放在源树中的习惯。相反，将构建树创建为源树的同级树。旨在保持您的源代码树不受构建影响。所需要的只是让某人在源树中创建一个目录，其名称与您用于构建树的目录相同，否则就会出现问题（我不止一次看到过这种情况！）。您可能还想为一个源树设置多个构建树，例如一个用于调试构建，另一个作为发布构建，因此将这些构建树放在源树之外也有助于保持源树不那么混乱。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
