mill.daemon

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.

This contains a list of frames each representing cached data from a single level of build.mill evaluation:

• frame(0) contains the output of evaluating the user-given tasks
• frame(1) contains the output of build.mill file compilation
• frame(2) contains the output of the in-memory MillBuildRootModule.BootstrapModule
• If there are meta-builds present (e.g. mill-build/build.mill), then frame(2) would contain the output of the meta-build compilation, and the in-memory bootstrap module would be pushed to a higher frame

If a level n fails to evaluate, then errorOpt is set to the error message and frames < n are set to RunnerState.Frame.empty

Note that frames may be partially populated, e.g. the final level of evaluation populates watched but not scriptImportGraph, classLoaderOpt or runClasspath since there are no further levels of evaluation that require them.

Logic around the "watch and wait" functionality in Mill: re-run on change, re-run when the user presses Enter, printing status messages, etc.