加快构建速度的技巧
有什么方法可以使软件构建/编译更快吗？我们有一个使用 makefile 的构建树 c、c++，新构建需要近 2 小时。我遇到过一些商业解决方案，例如 ElectricAccelerator、Sparkbuild，有没有等效的开源解决方案？
Is there any way to make software builds / compilation faster ? We have a build tree c, c++ using makefile that takes close to 2Hrs for fresh builds. I came across few commercial solutions like ElectricAccelerator, Sparkbuild, are there any opensource equivalent ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可能需要查看 distcc、ccache 当然，还有
-jmake 选项。You may want to look at distcc, ccache and, of course,
-jmake option.在谷歌上搜索可能有助于获取开源软件列表。
对于您的代码，您可以执行以下操作来减少构建时间：
A search on google might help in getting list of open source softwares.
W.r.t your code you can do the following to reduce build times:
在我们公司，我们有很多产品的构建时间较长，例如 3-6 小时。
我们使用了两种技术。
make的-j选项In our company we had lots of product that has longer build time like 3-6 hours.
There are 2 techniques we used.
-joption ofmake一种方法是简单地在更快的硬件上运行构建。我意识到这并不总是一个选择，但仍然需要考虑。
正如 @Martin 提到的，一些需要升级的特定子系统包括使用尽可能快的磁盘（例如 SSD）、添加更多 RAM、更快的 CPU（以及更多内核，如果您的编译器可以使用它们），并确保正在构建的文件都是构建机器本地的（而不是在网络上）。
您还应该为构建过程提供尽可能多的资源池，因此从构建计算机中剥离所有与构建无关的进程和应用程序。这将减少任何资源争用。
One way is to simply run the build on faster hardware. I realize that this isn't always an option, but it's still something to consider.
As @Martin mentions, some specific sub-systems to upgrade include using as fast a disk as you can, like an SSD, adding more RAM, a faster CPU (and more cores, if your compiler can use them), and making sure the files being built are all local to the build machine (not on the network).
You should also give the build process as much of this resource pool as possible, so strip off all non-build-related processes and applications from the build machine. This will reduce any resource contention.
您没有指定您的配置软件，但我们发现了clearcase的问题。由于它逐个文件评估规则的方式，仅打开文件就可能成为瓶颈。仅当您被clearcase“困住”时才考虑进一步阅读。
因此，我们发现通过更改头文件的包含保护，您可以将构建时间缩短到 1/30（对我们来说确实如此）。
基本上，在你的头文件中，你在顶部有一个包含保护，例如：
然后在其他地方，你#include foo.h。是的，我们发现，由于类型文件的一些可怕的耦合，以及我们编译的每个 .c 文件中的一些常见标头被包含了数百次。由于 Clearcase 设计缺陷，这意味着打开每个文件数百次只会忽略内容并再次关闭文件。
所以.. 不只是对 foo 使用#include，而是使用守卫有条件地包含 foo。通常这是不好的做法，也是一个可怕的维护噩梦（如果有人开始更换守卫）。
所以..在你的.c文件中，你最终会做这样的事情：
就像我说的...不好的做法，但是如果你使用clearcase并且它会花费3-4个构建时间（就像我们一样）..可能值得考虑（或者只是在 Clearcase 之外复制整个树）。或者抛弃透明外壳。或者在类型相互依赖方面做得更好。
我们能够“修复”一些最过度使用的包含项，并在构建时间上实现相当显着的改进。
You didn't specify your configuration software, but we discovered a problem with clearcase. Because of how it evaluates rules on a file by file basis, just opening a file can be a bottleneck. Only even consider reading further if you are "stuck" with clearcase.
So, we discovered that by changing your include guards for header files, you can cut your build time to 1/30th the time (for us it did).
Basically, in your header files, you have an include guard at the top like :
Then off somewhere else, you #include foo.h. Right, well, we found that due to some horrible coupling of types files and such that some common headers got included hundreds of times for each .c file we compiled. With the clearcase design flaw, that mean opening each of those files hundreds of times only to ignore the contents and close the file again.
So.. instead of just a #include for foo, use the guard to conditionally include foo. Normally this is bad practice and a horrible maintenance nightmare (if someone starts changing the guards).
So.. in your .c file, you'd end up doing something like :
Like I said... bad practice, but if you are using clearcase and its biting you with 3-4 build times (like we had)... may be worth considering (or just making a copy of your whole tree outside clearcase). Or ditch clearcase. Or do a better job with type inter-dependencies.
We were able to "fix" some of the most over-used includes and achieve pretty dramatic improvement in build times.
如果正确使用预编译头文件，可以大大减少构建时间。
Precompiled headers can, if employed correctly, drastically reduce build times.
我们使用
distmake、ccache和makefile-generator的组合来创建可并行的 makefile。C/C++构建可以非常好地并行化；通常所有.o文件都可以并行编译。Distmake是 make 的分布式实现，基于 gnu make 并在 GPL 下发布。我维护它。它允许您跨多个主机并行化。这要求所有主机具有相同的文件系统视图，例如。 NFS，以便相同的命令可以在任何构建主机上运行。如果您有这个选项，关闭优化往往会产生更快的构建速度。
如果您已经使用并行构建架构并且它仍然很慢，您可能只需要研究它。用秒表观察其进度并查看瓶颈所在。寻找您可能没有想到的“长杆”。祝你好运。
We use a combination of
distmake,ccache, and amakefile-generatorthat creates a parallelizable makefile.C/C++builds can parallelize extremely well; often all.ofiles can be compiled in parallel.Distmakeis a distributed implementation of make, based on gnu make and released under GPL. I maintain it. It lets you parallelize across multiple hosts. This requires all the hosts have the same view of the filesystem, eg. NFS, so that the same command can run on any build host.Turning off optimizations will tend to produce faster builds, if you have that option.
If you already use a parallel build architecture and it's still slow, you may just need to study it. Watch its progress with a stopwatch and see where it bottlenecks. Look for "long poles" that perhaps you didn't expect. Good luck.