问题标签 [incremental-compiler]

我改进了我们的构建系统并激活了增量构建和编译，如本问题中所述。令我失望的是，增量编译并没有像阅读Gradles 博客文章所期望的那样缩短构建时间。

经过一番调查，我意识到问题在于，即使我只在应用程序深处的某个小类中添加了评论，显然几乎整个代码库都被重建了。事实上，我接触哪个类并不重要，Gradles--debug输出显示它基本上总是重新编译 476 个类。

476 个类的增量编译在 12.51 秒内完成。

虽然我知道public static更改文件中的常量会触发完全重新编译（只是稍微慢一点），但我不明白如何正确分解类依赖项以便增量编译真正起作用。确定影响增量编译的类依赖项的确切规则是什么？我可以在这里阅读一些示例，但它似乎根本不适用于我们的（相当标准的）项目。

我自己的一些测试产生了以下结果：

为什么 A 在实现细节而不是 B 的接口发生变化时需要重新编译？

我还尝试在接口 C 后面“隐藏”B。我认为这将是打破依赖关系的正确方法（尽管通常非常麻烦）。但事实证明它根本没有帮助。

在我看来，我们有这么大的依赖 blob，我不确定这是否可以合理地改变，即使我认为我们有一个设计合理的代码库。Android 开发人员中是否有可以有效改进增量编译的最佳实践、指南或设计模式？

我确实想知道其他人是否和我们有同样的问题，如果没有，你做了什么？

这是上下文：我使用微控制器，将生成的二进制文件写入内部闪存，并从那里执行。闪存以 4KiB 块进行擦除和写入。闪光器足够聪明，可以跳过不需要更改的块。

在开发过程中，通常每天进行数十次微小的更改并重新编译和重新刷写。

我想要实现的是，如果可能的话，让链接器尽可能地保留现有结构。例如，如果我在某处删除了一个 if-check，代码会变小几个字节，并且所有后续信息都会移动几个字节，因此整个闪存被擦除并重新编程。

如果链接器能够以某种方式在链接符号之间添加填充，则通常可以跳过闪存的大部分而不覆盖。当代码变大时，这显然不起作用。

是否有任何 gcc 选项可以帮助自动化此类任务（无需手工制作大量链接器脚本）？是否有任何编译器至少部分支持此类行为？

我了解增量编译是什么：当编译器只编译您编辑的代码而不是全部时。但是，将代码分离为 .h 和 .c/.cc 文件以及 C++ 中的 makefile 如何帮助增量编译？

我们有一个大型 Typescript 项目，我们正在尝试改进增量编译时间，这有时会占据开发时间。对于很多文件，如果我们遵循所有的import语句，我们将到达项目的大部分文件，因此增量编译可能会非常慢。我们正在努力减少此图中的连接性，但我们也注意到，对于我们在 Typescript 文件中所做的一些更改，导入文件不会使用 --incremental 或在监视模式下重新编译。

例如，更改类中的方法主体（但不更改其签名）不会导致重新编译导入该类的文件。此外，将（软和硬）私有字段添加到类或文件本地声明似乎不会导致重新编译导入程序。

但是，我们注意到，当使用 mixin 模式 ( https://www.typescriptlang.org/docs/handbook/mixins.html ) 时，对 mixin 类的任何更改都会导致重新编译所有导入器，甚至添加硬私有字段。似乎使用导入/导出类型对依赖项没有任何影响，但我们却没有找到相关文档。

如果增量编译，是否有正式的文档说明什么构成了依赖项？这个依赖图是否可以从编译器（或增量编译输出）获得？更实际的是，有没有一种方法可以在不创建私有字段和方法实现的编译依赖项的情况下使用 mixin？我们只能通过为所有涉及的类引入接口来解决这个问题，但这非常麻烦并且会导致其自身的问题。似乎不可能将项目划分为子项目并使用项目引用，因为在任何这样的划分中我们都会得到循环依赖。

为了进行 strictNull 检查，我们尝试按照建议逐步将它们引入我们的代码，但是将一个文件添加到检查文件列表中也会添加它传递导入的所有文件（或者看起来如此）。是否有此处使用的依赖关系的正式文档？它与增量编译的相同吗？

我对 Java 注释处理上下文中的增量环境到底是什么感到困惑。一个例子是高度赞赏的。

以下是Filer的 Javadoc 的引用：

文件创建方法采用可变数量的参数，以允许将原始元素作为提示提供给工具基础架构，以更好地管理依赖关系。原始元素是导致注释处理器尝试创建新文件的类型或包（表示包信息文件）。例如，如果注释处理器尝试创建源文件 GeneratedFromUserSource，以响应处理

UserSource 的 type 元素应作为创建方法调用的一部分传递，如下所示：

如果没有原始元素，则不需要传递。此信息可在增量环境中用于确定是否需要重新运行处理器或删除生成的文件。非增量环境可能会忽略原始元素信息。

我理解，例如，在上面的例子中，如果@Generated被删除，那么下次运行编译时，之前生成的GeneratedFromUserSource将被删除。（据推测，显然，一些实现com.sun.tools.javac.processing.JavacFiler完全忽略了原始元素。）这是否使它成为增量？我没有任何需要重新运行处理器的例子。

为了让事情更混乱，我偶然发现了这个问题，显然，有三种类型的处理器：

1. 动态，2. 隔离，3. 聚合

并且增量处理器需要在 META-INF 中与非增量处理器不同的位置注册。我目前正在使用@AutoService我认为不支持此注册的。

由于（大多数情况下）不允许覆盖Filer，我希望能澄清一下是什么使处理器增量。