4

sbt 维护任务之间的依赖关系，并且可以很容易地推断出结果图。另一方面，略读源代码，增量编译逻辑似乎更加不透明。我希望能够做以下事情：

  • 相当于“如果我[以这种方式]修改了这个界面，什么会失效？”
  • 构建一个图表，说明修改不同的类接口如何影响构建的其余部分。考虑到 Scala 中的隐式依赖关系有多复杂，绘制 scala 导入依赖关系并不是一个特别好的近似。似乎 sbt 必须以某种形式维护这些信息才能进行增量编译，所以我“只”需要弄清楚如何访问它并希望它的形式适合我的用例。

这些都可行吗？我不反对编写 sbt 插件，但希望获得有关如何继续的提示。

编辑：看起来Relation'susesInternalSrc(dep: File): Set[File]可能很有希望。这是否捕获了 sbt 的所有依赖知识？

编辑 2：更有希望的是，DotGraph在 sbt 源代码树中有一个对象。它没有文档，谷歌也没有任何关于它的人类可读文本。如果我能弄清楚如何使用它，我会发布一个答案。

4

1 回答 1

3

示例console-project会话：

> val (s, a) = runTask(compile in Compile, currentState)
> DotGraph.sources(a.relations, file("source-graph"), Nil)

source-graph是一个包含两个点文件的目录，一个带有源依赖项，一个带有二进制文件。您也可以直接与Relationsa.relations类型进行交互，正如问题中所建议的那样，它确实捕获了所有 sbt 的依赖知识。在 0.13 中，还将提供有关哪些依赖项是由于从另一个源文件中的某些内容继承而来的信息。

就修改源文件如何影响失效而言，它是非常粗粒度的。对任何非私有签名的任何更改都将源标记为已更改。在 0.12 及更早版本中，这至少会使直接依赖关系失效，甚至更多。在 0.13 中，这只会使直接依赖项无效，但继承的依赖项除外，它们是可传递无效的。目前没有办法看到当源文件的非私有 API 被修改时，什么会失效，除非这样做。

于 2013-06-21T20:21:13.860 回答