From ea7fceb6e56f53bde3517586dfc57e10a605a524 Mon Sep 17 00:00:00 2001 From: Li Haoyi Date: Wed, 12 Dec 2018 22:15:38 +0800 Subject: First pass at splitting out worker-api from mill core. (#504) This reduces the {scala,scalajs,scalanative}-worker dependency from the entirety of Mill to a much narrower `mill.api` module. This reduces the amount of classpath pollution within these workers, should mean they're much faster to download the first time, and reduces the amount of random junk they would pull in if they were to be used outside of the Mill project. The interactions between the various *Modules and their *WorkerImpls has been narrowed down to the `*.api` modules, which only depend on other `*.api` modules. A lot of things have been moved around; user code is unlikely to break, but it's possible some will if it references classes that have been moved around. Forwarders have been left for the few internal classes that Mill uses in it's own `build.sc`, to support bootstrapping. Third-party code which breaks should be a straightforward to fix just by updating imports The `*.api` modules have minimal dependencies (mostly uPickle and os-lib) and minimal code. There is still a bunch of implementation code in there: some of it defining data-types that are commonly sent across the module/worker interface (`Agg`, `PathRef`, ...), and some of it just general helper functions that are needed both in modules and workers. The latter code isn't strictly API definitions, but for now is small enough it's not worth splitting into it's own module --- docs/pages/4 - Tasks.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/pages/4 - Tasks.md b/docs/pages/4 - Tasks.md index e69ae662..78a6e58e 100644 --- a/docs/pages/4 - Tasks.md +++ b/docs/pages/4 - Tasks.md @@ -176,10 +176,10 @@ There are several APIs available to you within the body of a `T {...}` or `T.command {...}` block to help your write the code implementing your Target or Command: -### mill.util.Ctx.Dest +### mill.api.Ctx.Dest - `T.ctx().dest` -- `implicitly[mill.util.Ctx.Dest]` +- `implicitly[mill.api.Ctx.Dest]` This is the unique `out/classFiles/dest/` path or `out/run/dest/` path that is assigned to every Target or Command. It is cleared before your task runs, and @@ -188,10 +188,10 @@ artifacts. This is guaranteed to be unique for every `Target` or `Command`, so you can be sure that you will not collide or interfere with anyone else writing to those same paths. -### mill.util.Ctx.Log +### mill.api.Ctx.Log - `T.ctx().log` -- `implicitly[mill.util.Ctx.Log]` +- `implicitly[mill.api.Ctx.Log]` This is the default logger provided for every task. While your task is running, `System.out` and `System.in` are also redirected to this logger. The logs for a @@ -202,10 +202,10 @@ specific output is also streamed to a log file on disk, e.g. `out/run/log` or Messages logged with `log.debug` appear by default only in the log files. You can use the `--debug` option when running mill to show them on the console too. -### mill.util.Ctx.Env +### mill.api.Ctx.Env - `T.ctx().env` -- `implicitly[mill.util.Ctx.Env]` +- `implicitly[mill.api.Ctx.Env]` Mill keeps a long-lived JVM server to avoid paying the cost of recurrent classloading. Because of this, running `System.getenv` in a task might not yield -- cgit v1.2.3