diff options
author | Guillaume Martres <smarter@ubuntu.com> | 2018-08-25 18:28:59 +0900 |
---|---|---|
committer | GitHub <noreply@github.com> | 2018-08-25 18:28:59 +0900 |
commit | 146d58bc5d98da1d142758f974d4d5de6f5948bf (patch) | |
tree | 1395134291f0bdf474ba8e7e6d846bbdb04a126b /scalanativelib | |
parent | e4d16b38e76884c06ce74903a318b1a148c7a63d (diff) | |
download | mill-146d58bc5d98da1d142758f974d4d5de6f5948bf.tar.gz mill-146d58bc5d98da1d142758f974d4d5de6f5948bf.tar.bz2 mill-146d58bc5d98da1d142758f974d4d5de6f5948bf.zip |
Fix incremental compilation when a Scala project depends on a Java project (#414)
* Upgrade ammonite to 1.1.2-30-53edc31
This is mainly to get https://github.com/lihaoyi/Ammonite/pull/851 which
should reduce the amount of unnecessary work done by incremental
compilation in the Mill build. This requires some code changes since
this means we now depend on a more recent version of coursier, as a
side-effect this means that we do not depend on scalaz anymore.
Also use the same ammonite version in the Mill build and in
ScalaModule#ammoniteReplClasspath.
Also remove an incorrect dependency in the caffeine integration test.
This was always wrong but did not start failing until this commit,
probably due to dependencies appearing in a different order on the
classpath.
* Rename ScalaWorker to ZincWorker
Starting with the next commit, it will be used in Java-only projects
too, so the name is misleading.
* Upgrade to Zinc 1.2.1
* Fix incremental compilation when a Scala project depends on a Java project
Before this commit, JavaModule#compile simply called javac
unconditionally, thus generating new classfiles every time. But if a
Scala project depends on a Java project, this will throw off the
incremental compilation algorithm which will unnecessarily recompile
files. To avoid this we now use Zinc to compile Java projects too (as a
bonus this means that Java compilation becomes incremental). This
required some refactoring in ZincWorkerImpl to be able to compile stuff
without having to pass Scala-specific options.
The issue solved by this commit could be reproduced by running in the
Mill repository:
$ mill main.compile
$ mill -i
@ main.compile()
and observing that before this commit, the `main.compile()` call ended
up recompiling code.
Diffstat (limited to 'scalanativelib')
-rw-r--r-- | scalanativelib/src/mill/scalanativelib/ScalaNativeModule.scala | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/scalanativelib/src/mill/scalanativelib/ScalaNativeModule.scala b/scalanativelib/src/mill/scalanativelib/ScalaNativeModule.scala index 5e4fc471..748afb79 100644 --- a/scalanativelib/src/mill/scalanativelib/ScalaNativeModule.scala +++ b/scalanativelib/src/mill/scalanativelib/ScalaNativeModule.scala @@ -46,7 +46,7 @@ trait ScalaNativeModule extends ScalaModule { outer => override def artifactSuffix: T[String] = s"${platformSuffix()}_${artifactScalaVersion()}" trait Tests extends TestScalaNativeModule { - override def scalaWorker = outer.scalaWorker + override def zincWorker = outer.zincWorker override def scalaOrganization = outer.scalaOrganization() override def scalaVersion = outer.scalaVersion() override def scalaNativeVersion = outer.scalaNativeVersion() @@ -238,7 +238,7 @@ trait TestScalaNativeModule extends ScalaNativeModule with TestModule { testOute // creates a specific binary used for running tests - has a different (generated) main class // which knows the names of all the tests and references to invoke them object testRunnerNative extends ScalaNativeModule { - override def scalaWorker = testOuter.scalaWorker + override def zincWorker = testOuter.zincWorker override def scalaOrganization = testOuter.scalaOrganization() override def scalaVersion = testOuter.scalaVersion() override def scalaNativeVersion = testOuter.scalaNativeVersion() |