【发布时间】：2018-09-30 08:13:49
【问题描述】：
我有一个基于 GPR 的大型项目，编译可能需要 30 多分钟。
分析了构建过程后，我注意到许多明显的低效率（多次调用 gprbuild 而不是聚合、过度使用替代文件而不是配置等）。我想知道是否有某种方法可以“分析”构建过程以查看需要这么长时间。
特别是当单个文件发生更改并且其中存在错误时，重新编译大约需要 5 分钟。从理论上讲，应该很快意识到必须重新编译该文件（它是唯一需要重新编译的文件）并开始编译过程，迅速发现错误。
从详细的输出来看，仅解析用于定义构建的大量 gpr 文件网络似乎需要相当长的时间，但我想知道它大部分时间都花在了哪里。
因此我的问题是：是否可以分析 gprbuild 完成的构建？如果有，怎么做？
【问题讨论】：
-
根据我的经验，
gprbuild很难使用单独定义的开关管理大量源文件。我从来没有足够在意检查问题是否特定于基于每个源文件定义开关，或者问题是否是纯项目文件大小。