源代码依赖关系
假设我有一堆 C++ 文件：A.cc、B.cc、C.cc 及其关联的头文件。 A.cc 使用 B.cc 中的类等等。
现在假设我要构建源文件。在预处理阶段之后，理论上我可以同时编译（而不是链接）所有文件吗？ （A.cc -> A.obj，...）
我只是想知道是否有一个时候我必须等到完成 A.cc 编译后再编译 B.cc。
Suppose I have a bunch of C++ files: A.cc, B.cc, C.cc, and their associated header files. A.cc makes use of classes in B.cc and so on.
Now say I want to build the source files. After the preprocessing phase, can I theoretically compile (not link) all the files simultaneously? (A.cc -> A.obj, ...)
I'm just wondering if there is ever a time when I would have to wait until I finish compiling A.cc before compiling B.cc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，除非您确实做了一些奇怪的事情，否则
B.cc的编译将不依赖于编译A.cc的结果（反之亦然）。这就是为什么 make -j（并行运行多个“作业”，即进程，每个同时编译一个文件）是一种流行的用法，尤其是在多核机器上（但不仅限于这些，因为即使没有多个核心，少量并发作业最终也可能比任意序列化的同一组作业更快地完成——一个作业可能会被阻塞等待用于磁盘 I/O，而另一个则在编译过程中搅动 CPU 密集型部分...)...只要您确实有足够的可用物理 RAM，即；-)。No, unless you're doing something weird indeed, the compilation of
B.ccwill not depend on the result of compilingA.cc(and vice versa). That's whymake -j(running multiple "jobs", i.e., processes, in parallel, each compiling a file at the same time) is a popular usage, especially of course on multi-core machines (but not those only, since even without multiple cores a small number of simultaneous jobs may in the end finish faster than the same set of jobs arbitrarily serialized -- one may be blocked waiting for disk I/O while the other is churning a CPU-intensive part of the compilation...)... as long as you do have enough available physical RAM, that is;-).这就是标题的用途，对吗？ make -j N 将为您执行此操作，尽管它是基于易出错的用户生成的 Makefile 执行的。
That is what the headers are for, right? make -j N will do this for you, although it does it based on fallible user-generated Makefiles.
只有一种情况您确实需要这种依赖性：当一个文件生成稍后编译的 C++ 代码时。 Make 足够灵活来支持这一点。但是当您想到您的常规项目时，不，您不希望也不应该有这样的依赖关系。
There is only one case where you actually want such dependence: when one file generates C++ code that is compiled later. Make is flexible enough to support this. But when you think of your regular projects, no, you don't want and should not have such dependencies.