mill.define

Represents an unstructured sequence of command-line arguments that can be passed to Mill commands; similar to mainargs.Leftover.

Represents a module at the root of a module tree. This can either be a mill.define.RootModule representing the build.mill file, or a mill.define.ExternalModule provided by a library.

Models "cross-builds": sets of duplicate builds which differ only in the value of one or more "case" variables whose values are determined at runtime. Used via:

object foo extends Cross[FooModule]("bar", "baz", "qux")
trait FooModule extends Cross.Module[String]{
 ... crossValue ...
}

Macro to walk the module tree and generate mainargs entrypoints for any Task.Command methods that it finds.

Note that unlike the rest of Mill's module-handling logic which uses Java reflection, generation of entrypoints requires typeclass resolution, and so needs to be done at compile time. Thus, we walk the entire module tree, collecting all the module Class[_]s we can find, and for each one generate the mainargs.MainData containing metadata and resolved typeclasses for all the Task.Command methods we find. This mapping from Class[_] to MainData can then be used later to look up the MainData for any module.

A module which you can override moduleDirectChildren to dynamically enable or disable child modules at runtime

An implicit that provides the lexically-enclosing class at the point at which it is resolved

A module defined outside of the build.mill file, and is instead provided builtin by some Mill library or plugin

Implementors should make sure, the final override of millDiscover happens in the final object.

  override protected def millDiscover: Discover = Discover[this.type]

Defines various default JSON formatters used in mill.

Represents a namespace within the Mill build hierarchy, containing nested modules or tasks.

Module is a class meant to be extended by traits only, in order to propagate the implicit parameters forward to the final concrete instantiation site so they can capture the enclosing/line information of the concrete instance.

The contextual information provided to a mill.define.Module or mill.define.Task

Used to refer to a module from another module without including the target module as a child-module of the first.

Represents a task that can be referenced by its path segments. Task{...} targets, Task.Input, Task.Worker, etc. but not including anonymous Task.Anon or Task.traverse etc. instances

A wrapper around os.Path that calculates it's hashcode based on the contents of the filesystem underneath it. Used to ensure filesystem changes can bust caches which are keyed off hashcodes.

Used to mark a module in your build.mill as a top-level module, so it's tasks can be run directly e.g. via mill run rather than prefixed by the module name mill foo.run.

Only one top-level module may be defined in your build.mill, and it must be defined at the top level of the build.mill and not nested in any other modules.

A Target is a NamedTask that is cached on disk; either a TargetImpl or an InputImpl

Models a single node in the Mill build graph, with a list of inputs and a single output of type T.

Generally not instantiated manually, but instead constructed via the Target.apply & similar macros.

The mill.define.Target companion object, usually aliased as T, provides most of the helper methods and macros used to build task graphs. methods like Task.apply, Task.sources, Task.command allow you to define the tasks, while methods like Task.dest, Task.log or Task.env provide the core APIs that are provided to a task implementation

Represents the data and utilities that are contextually available inside the implementation of a Task.

Provides access to various resources in the context of a current execution Target.

A Module that has a defaultCommandName that will be automatically executed if the module name is provide at the Mill command line