什么是CMake“项目”的正确使用，指示 [英] what is the proper use of the CMake "project" directive
问题描述
我有一个大型的代码库，它构建了几十个库和几个可执行文件。
代码库分层分层，库在几乎每个级别生成。
我经历过并在每个目录下放置一个CMakeLists.txt文件来构建每个库。
在每个CMakeLists.txt中，我使用了project（xxx）指令。这为我定义了PROJECT_NAME，PROJECT_SOURCE_DIR和PROJECT_BINARY_DIR变量，我明智地使用它。
然而，其中一个团队不满意这种方法，因为他找不到任何其他人做过这个的真实世界的例子。他经常引用KitWare的例子不使用这种方法，因此我们也不应该。
他倡导的替代方法是在每个makefile中设置这些变量，看起来很像project给你。
我真的看不到他的观点，而且还没有说服他。任何人都可以用这种方式使用项目指令的缺点。
我抛弃你的集体智慧？
< projectName> ; _SOURCE_DIR ，但这不是主要的优势。如果你给CMake一个项目名称，那么它将为每个子项目在自己的目录中生成构建目标。这意味着无论您使用GNU Make，Eclipse CDT，XCode还是任何其他支持的生成器，您都可以单独构建子项目。 您可以通过 PROJECT_NAME访问当前的项目名称（例如使用GNU Make）。每个子项目都有自己的完整构建系统。 ，根项目名称由 CMAKE_PROJECT_NAME 。
编辑：我刚刚实现以下将标准的CMake行为为任何其构建目标，无论他们是否是项目。我会在这里保留一般信息，但它不与答案无关：
假设我有一个C ++库，我可以生成三个二进制可执行文件; 主和 tests / test1 和 examples / ex1 。我可以运行make在目录中我调用CMake从ALL目标，运行 make ex1 ，或者我可以更改目录为 examples / 并使用该目录中的 make 构建示例。这将构建所有的依赖项目和库，即使它们在目录结构中的其他地方，但不会构建 Main 或 tests / test1 或其依赖于 examples / ex1 的任何库。如果我然后从主目录运行make，它将不会重建 examples / ex1 依赖的任何库，除非它们的源代码已更改。
I have a large-ish codebase which builds several dozen libaries and several executables.
The codebase is broken down hierarchically and libraries are build at pretty much every level.
I've gone through and placed a CMakeLists.txt file at each directory to build each library.
In each CMakeLists.txt I have used the "project( xxx )" directive. This has defined for me PROJECT_NAME, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR variables which I make judicious use of.
However, one of the team is unhappy with this approach as he can't find any real world examples of anyone else having done this. He often cites the KitWare examples as not using this approach and therefore neither should we.
The alternative approach he is advocating is to set these variables up in each makefile which seems much like what "project" gives you.
I really can't see his point and am making little headway in convincing him otherwise. Can anyone shed any light on the downsides of using the project directive in this way.
I throw myself on your collective wisdom?
Firstly, it enables you to use <projectName>_BINARY_DIR and <projectName>_SOURCE_DIR, but that's not the main advantage. If you give CMake a project name then it will generate build targets for each of the sub-projects in their own directories. This means that whether you're using GNU Make, Eclipse CDT, XCode, or any of the other supported generators you can build sub-projects individually. For instance with GNU Make each sub-project has its own full build system from it's own directory.
You can access the current project name through PROJECT_NAME, and the root project name by CMAKE_PROJECT_NAME.
Edit: I've just realised the below will be standard CMake behaviour for any of its build targets whether they're projects or not. I'll keep it here for general information but it is not pertinent to the answer:
Assume I have a C++ library, and I can generate three binary executables; Main and tests/test1, and examples/ex1. I can either run make in the directory I called CMake from with the ALL target, run make ex1, or I can change directory to examples/ and build the examples with make from that directory. This will build all of the dependent projects and libraries even if they're somewhere else in the directory structure but won't build Main or tests/test1 or any libraries that they depend on that examples/ex1 doesn't. If I then run make from the main directory, it won't rebuild any of the libraries that examples/ex1 depends on unless their source has changed.
这篇关于什么是CMake“项目”的正确使用，指示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
