我目前正在尝试提高构建计算机的性能。每次提交（svn）后排队的标准构建大约需要40分钟。如果在提交时已经排队了，我们就不会添加另一个。因此每个构建都有1+提交的更改。由于提交可能没有对所有项目进行更改，因此只需重建受影响的项目即可减少构建时间。
我不知道如何找出需要构建的项目。有没有办法可靠找出受触发构建的提交影响的内容？我首先想过浏览.dpr文件并检查引用文件的变化，但并不是所有文件都列在那里，因为我们也使用了搜索路径......
如果没有，是否至少有办法确定项目是否肯定不会受到影响？老实说，我不太清楚如何处理这个问题...
答案 0 :(得分：2)
以下不是您问题的“答案”，但可能有助于进一步思考。
不考虑给定项目使用的其他类型的资源（例如.RC和.Inc文件），而不知道哪些源文件，包括它使用的所有单元，我看不出你怎么能证明这个命题“这个项目不会受到影响。“通过给定的提交。
另一方面，假设您可以生成由提交更改的项目和源文件的列表，因此通过偶尔重新编译所有项目，您可以获得由此生成的DCU列表。
使用对源文件的不同更改集重复多次上述过程，您应该能够收集.Pas更改和重新编译的结果.DCU之间以及重新编译和生成的DCU项目之间的一些统计相关性。
对这些相关性的分析可能允许您确定哪些项目在给定时需要重新编译的可能性大于X％.Pas文件已更改。
我想你最终会得到一些启发式方法，可以确定在给定单位的变化和一些确定性规则之后应该重新编译哪个项目。显而易见的是，一旦观察到对单元A的改变引起项目Z的重新编译，每当A随后改变时，Z应该被重新编译。当然，一旦项目被确定性规则标记为肯定，就不需要考虑提交中更改的其他源文件。
另一件事是你可以侧面解决需要分析.Pas文件USES依赖关系的问题，以确定给定项目依赖于哪些.Pas文件，通过完成项目的完整构建并制作一个列表。结果产生DCU。
Btw，因为这个问题似乎都是关于列表和规则的，所以在Prolog中编程会很有趣（Amzi Prolog有一个很好的Delphi逻辑引擎包装器，我过去曾用过类似的东西）。 / p>答案 1 :(得分：1)
您可以尝试并行构建过程并使用RAM驱动器来加速它。 在我的工作中，我们使用Ant进行构建。它可以以并行方式运行某些目标，它可以提高编译性能x4次和更多次（取决于线程数）。
如果您无法加快构建过程。我有两种方法：
您可以编写应用程序，它遍历项目文件（.dpr）并解析它递归使用的每个.pas文件。在此之后，您可以将文件列表与提交日志进行比较，并决定是否构建此项目。对所有项目重复一遍。
保存dcc32.exe构建日志并在下一次构建时使用它来查找提交中的文件。如果找到了文件，则必须重建项目。一个问题 - 未涵盖的新文件，但如果某些文件在上次提交时添加，则可以强制构建。