考虑这样的项目 -
CMakeLists.txt
|
|------/Project1
| |
| |-----CMakeLists.txt
| |
| |-----/Project1.lib1 //needs Project3.lib1
| | |
| | |-----CMakeLists.txt
| | |-----lib1.cpp
| |
| |-----/Project1.lib2 //needs Project3.lib1
| |-----/Project1.lib3
| |-----...
| |-----/Project1.libn //some need Project3.lib1
|
|------/Project2 //Totally independent
| |
| |-----/Project2.lib1
| |-----/Project2.lib2
|
|------/Project3
|
|-----/Project3.lib1
当然，所有子目录都有cmakelists.txt和代码文件。和每个cmakelists.txt用 add_subDirectory 。
每个Projectx.liby的Cmakelists都有一个 add_library(name srcs(，其中一些取决于 project3.lib1 。不幸的是， Project1 非常波动，大，情况变化很快。那里有很多子项目，恐怕有人可能会忘记将依赖性保持在最新的依赖。拥有一千个add_依赖项(project1.liby project3.lib1(在整个Project1上散布会很痛苦。尤其是当涉及到多核心时(make -j8(正确的依赖树是必不可少的。否则，我们可能会遇到零星问题，因为 project1.liby 由于 project3 而尚未构建，但仍需要。因此，我想做的就是告诉CMAKE，只要尚未构建/更新Project3，CMAKE甚至不要潜入Project1-folter。像
//Project1/CMakeLists.txt
#...
Project (Project1)
add_dependencies (Project1 Project3)
# or add_dependencies (Project1 Project3.lib1)
#...
你们对我有什么线索？
thanx很多！
首先：尽可能优于 target_link_libraries而不是 add_dependencies。特别是在库之间表达依赖关系时，它几乎总是更好的工具。如果您有充分的理由这样做，则仅诉诸add_dependencies(例如。
我知道这种情况在大多数程序员中触发了干反射，但是请记住，构建系统代码的权衡与普通代码不同。更明确地通常会提高整个系统的可维护性，即使这意味着在构建脚本中重复很多东西。
还请记住，CMAKE确实设计为使用目标作为组织构建的基本概念。因此，从建筑树的物理布局中确定依赖性，如果您不小心，从长远来看，可能会引起严重的头痛。因此，即使您绝对确定要摆脱必须反复写出依赖性，但根据定义目标定义的目录可能不是最好的方法。
说的话，如果您仍然确信您想做的是真正适合您项目的解决方案，那么link_libraries确实可以做到这一点。
作为最后的警告，我给您留下了link_libraries手册中的报价：
NOTE ：
target_link_libraries()命令应尽可能优选。库依赖性自动链接，因此 很少需要链接库的目录范围的规范。
您在示例中提到的是，并非所有Project1.libN S确实对Project3具有依赖性。这清楚地表明，您应该以每个目标的基础明确对依赖项进行建模。正如您自己说的那样，依赖树反映项目的实际依赖性至关重要。确保这样做的唯一方法是正确写出所有内容并确保您的开发人员也了解如何做到这一点。