Multithreading 尽管有-j选项，但仍会在目标链接上产生瓶颈

假设我有一个由两个目标a和B组成的CMake项目，每个目标都有要编译的源文件

如果我使用-jN选项构建（其中N是编译作业的数量，我将其设置为机器上的逻辑核数量），CMake将通过并行编译其所有源文件来开始构建。如果文件多于逻辑核，则我的计算机上的处理器负载现在是最大的

然后，它将链接一个，使用一个内核，而不启动其他任何东西。这是一个主要的瓶颈

---

只有在这之后，它才能通过启动N个B源代码的N个并行编译作业来构建B（如A）。然而，B中的任何一个绝对不依赖于A。或者，如果有，我不能说，也希望CMake告诉我，我想这就是我问题的前半部分

---

第二，假设B对A没有依赖性，我能告诉CMake尽快开始建造B吗？或者说是在一开始就开始建造吗？

“但是B对A绝对没有依赖性。或者如果有，我不能说，也希望CMake告诉我，我想这构成了我问题的前半部分。”-运行

make B

并查看是否将生成

A

。如果将构建

A

，则

B

具有来自

A

的依赖项（直接或间接）。“我告诉CMake尽快开始构建B，或者从一开始就开始？”-如果您在排序中有一些偏好，那么只需使用相应的参数运行几次

make

。普通

make

适用于没有首选项的情况。当然可以，但这不是内置的CMake选项。我必须编写一个CMakeLists，指定运行并行启动多个

make

命令的脚本。听起来很迂回、不自然、肮脏。嗯，我之前的描述可能不太好。我的意思是，CMake（和其他构建工具，如Make）不是按顺序构建的工具。与此相反，当事物之间没有严格的顺序，只有依赖关系时，才使用这种构建工具。考虑到这些依赖关系，构建工具按照满足依赖关系的顺序构建它们。这种基于依赖关系的构建工具对于“从一开始构建B”这样的首选项来说并不太好。这种偏好最好用“普通”的脚本语言（如shell或python）来表达，这是完全有道理的，我不想表达对构建顺序本身的偏好。只需将我的处理器及其所有内核加载到当前准备就绪（没有优先顺序）的任何东西（没有依赖项或所有依赖项都已完成）。

Ninja

似乎比

make

更好地并行化项目。