Adding/removing/renaming a class always forces dependent source file to recompile #2319
Comments
|
This issue is migration of gkossakowski#8. |
This was referenced Dec 16, 2015
gkossakowski
added a commit
to gkossakowski/sbt
that referenced
this issue
Jan 5, 2016
This commit implements invalidation of dependencies at class level both for inheritance and memberRef dependencies. However, information that determines api changes is still tracked mostly at source file level. Name hashes are tracked at source level (classes considered for invalidation are mapped back to source files before name hash lookup). For that reason, sbt#2319 is still not fixed. Api hashes are tracked per-class but only for top-level classes. It's not a final design but a quick hack to prove that class-based invalidation is working correctly. It was enough to scenario described in sbt#2320 fixed. This is shown in `class-based-inheritance` scripted test. The final design of api hashing will be that all publicly accessible classes will get their own separate hash. The sealed test is marked pending as described in notes of sbt#1104. Other thing to note is that we're getting close to being able to strip abstractions that deal with the fact that dependencies were tracked either as Relation[File, File] (for internal dependencies) or Relation[File, String] (for external dependencies). We track all dependencies uniformly as Relation[String, String] now.
gkossakowski
added a commit
to gkossakowski/sbt
that referenced
this issue
Jan 14, 2016
This commit implements invalidation of dependencies at class level both for inheritance and memberRef dependencies. However, information that determines api changes is still tracked mostly at source file level. Name hashes are tracked at source level (classes considered for invalidation are mapped back to source files before name hash lookup). For that reason, sbt#2319 is still not fixed. Api hashes are tracked per-class but only for top-level classes. It's not a final design but a quick hack to prove that class-based invalidation is working correctly. It was enough to scenario described in sbt#2320 fixed. This is shown in `class-based-inheritance` scripted test. The final design of api hashing will be that all publicly accessible classes will get their own separate hash. The sealed test is marked pending as described in notes of sbt#1104. Other thing to note is that we're getting close to being able to strip abstractions that deal with the fact that dependencies were tracked either as Relation[File, File] (for internal dependencies) or Relation[File, String] (for external dependencies). We track all dependencies uniformly as Relation[String, String] now.
gkossakowski
added a commit
to gkossakowski/sbt
that referenced
this issue
Jan 26, 2016
This commit implements invalidation of dependencies at class level both for inheritance and memberRef dependencies. However, information that determines api changes is still tracked mostly at source file level. Name hashes are tracked at source level (classes considered for invalidation are mapped back to source files before name hash lookup). For that reason, sbt#2319 is still not fixed. Api hashes are tracked per-class but only for top-level classes. It's not a final design but a quick hack to prove that class-based invalidation is working correctly. It was enough to scenario described in sbt#2320 fixed. This is shown in `class-based-inheritance` scripted test. The final design of api hashing will be that all publicly accessible classes will get their own separate hash. The sealed test is marked pending as described in notes of sbt#1104. Other thing to note is that we're getting close to being able to strip abstractions that deal with the fact that dependencies were tracked either as Relation[File, File] (for internal dependencies) or Relation[File, String] (for external dependencies). We track all dependencies uniformly as Relation[String, String] now.
gkossakowski
added a commit
to gkossakowski/sbt
that referenced
this issue
Jan 30, 2016
This commit implements invalidation of dependencies at class level both for inheritance and memberRef dependencies. However, information that determines api changes is still tracked mostly at source file level. Name hashes are tracked at source level (classes considered for invalidation are mapped back to source files before name hash lookup). For that reason, sbt#2319 is still not fixed. Api hashes are tracked per-class but only for top-level classes. It's not a final design but a quick hack to prove that class-based invalidation is working correctly. It was enough to scenario described in sbt#2320 fixed. This is shown in `class-based-inheritance` scripted test. The final design of api hashing will be that all publicly accessible classes will get their own separate hash. The sealed test is marked pending as described in notes of sbt#1104. Other thing to note is that we're getting close to being able to strip abstractions that deal with the fact that dependencies were tracked either as Relation[File, File] (for internal dependencies) or Relation[File, String] (for external dependencies). We track all dependencies uniformly as Relation[String, String] now.
eed3si9n
pushed a commit
to eed3si9n/sbt
that referenced
this issue
Apr 28, 2016
This commit implements invalidation of dependencies at class level both for inheritance and memberRef dependencies. However, information that determines api changes is still tracked mostly at source file level. Name hashes are tracked at source level (classes considered for invalidation are mapped back to source files before name hash lookup). For that reason, sbt#2319 is still not fixed. Api hashes are tracked per-class but only for top-level classes. It's not a final design but a quick hack to prove that class-based invalidation is working correctly. It was enough to scenario described in sbt#2320 fixed. This is shown in `class-based-inheritance` scripted test. The final design of api hashing will be that all publicly accessible classes will get their own separate hash. The sealed test is marked pending as described in notes of sbt#1104. Other thing to note is that we're getting close to being able to strip abstractions that deal with the fact that dependencies were tracked either as Relation[File, File] (for internal dependencies) or Relation[File, String] (for external dependencies). We track all dependencies uniformly as Relation[String, String] now.
|
This can be closed since it's fixed in sbt 1.0.0. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A.scalaB.scalacompileA.scala.compile. Both sources are recompiled becauseQintroduces a change to the hash for<init>(in the compilation unitA.scala).The underlying reason is that name hashing is tracking hashes for names at source file (compilation unit) level. The hash for
<init>includes hashes for bothA.<init>andQ.<init>. Therefore name hashing works well only when a member that is modified doesn't introduce any nested members. Therefore, it works for changes tovalanddefbut not toclassandobject.The text was updated successfully, but these errors were encountered: