summaryrefslogtreecommitdiff
path: root/scalanativelib
diff options
context:
space:
mode:
authorGuillaume Martres <smarter@ubuntu.com>2018-08-25 18:28:59 +0900
committerGitHub <noreply@github.com>2018-08-25 18:28:59 +0900
commit146d58bc5d98da1d142758f974d4d5de6f5948bf (patch)
tree1395134291f0bdf474ba8e7e6d846bbdb04a126b /scalanativelib
parente4d16b38e76884c06ce74903a318b1a148c7a63d (diff)
downloadmill-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.scala4
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()