mill.daemon.MillBuildBootstrap
See theMillBuildBootstrap companion object
class MillBuildBootstrap(projectRoot: Path, output: Path, keepGoing: Boolean, imports: Seq[String], env: Map[String, String], ec: Option[ThreadPoolExecutor], tasksAndParams: Seq[String], prevRunnerState: RunnerState, logger: Logger, needBuildFile: Boolean, requestedMetaLevel: Option[Int], allowPositionalCommandArgs: Boolean, systemExit: StopServer, streams0: SystemStreams, selectiveExecution: Boolean, offline: Boolean, reporter: EvaluatorApi => Int => Option[CompileProblemReporter], skipSelectiveExecution: Boolean, enableTicker: Boolean)
Logic around bootstrapping Mill, creating a MillBuildRootModule.BootstrapModule and compiling builds/meta-builds and classloading their RootModules so we can evaluate the requested tasks on the RootModule representing the user's build.mill file.
When Mill is run in client-server mode, or with --watch, then data from each evaluation is cached in-memory in prevRunnerState.
When a subsequent evaluation happens, each level of evaluateRec uses its corresponding frame from prevRunnerState to avoid work, re-using classloaders or workers to avoid running expensive classloading or re-evaluation. This should be transparent, improving performance without affecting behavior.
Attributes
- Companion
- object
- Source
- MillBuildBootstrap.scala
- Graph
-
- Supertypes
-
class Objecttrait Matchableclass Any
- Self type
Members list
In this article