mix compile.app — Mix v1.16.3

Search documentation of Mix

# View Source mix compile.app (Mix v1.16.3)

Writes an .app file.

An `.app` file is a file containing Erlang terms that defines your application. Mix automatically generates this file based on your `mix.exs` configuration.

In order to generate the `.app` file, Mix expects your project to have both `:app` and `:version` keys. Furthermore, you can configure the generated application by defining an `application/0` function in your `mix.exs` that returns a keyword list.

The most commonly used keys are:

- `:extra_applications` - a list of OTP applications your application depends on which are not included in `:deps` (usually defined in `deps/0` in your `mix.exs`). For example, here you can declare a dependency on applications that ship with Erlang/OTP or Elixir, like `:crypto` or `:logger`. Optional extra applications can be declared as a tuple, such as `{:ex_unit, :optional}`. Mix guarantees all non-optional applications are started before your application starts.

- `:registered` - the name of all registered processes in the application. If your application defines a local GenServer with name `MyServer`, it is recommended to add `MyServer` to this list. It is most useful in detecting conflicts between applications that register the same names.

- `:env` - the default values for the application environment. The application environment is one of the most common ways to configure applications. See the `Application` module for mechanisms to read and write to the application environment.

For example:

    def application do
      [
        extra_applications: [:logger, :crypto, ex_unit: :optional],
        env: [key: :value],
        registered: [MyServer]
      ]
    end

Other options include:

- `:applications` - all applications your application depends on at runtime. By default, this list is automatically inferred from your dependencies. Mix and other tools use the application list in order to start your dependencies before starting the application itself.

- `:mod` - specifies a module to invoke when the application is started. It must be in the format `{Mod, args}` where args is often an empty list. The module specified must implement the callbacks defined by the `Application` module.

- `:start_phases` - specifies a list of phases and their arguments to be called after the application is started. See the "Phases" section below.

- `:included_applications` - specifies a list of applications that will be included in the application. It is the responsibility of the primary application to start the supervision tree of all included applications, as only the primary application will be started. A process in an included application considers itself belonging to the primary application.

- `:maxT` - specifies the maximum time the application is allowed to run, in milliseconds. Applications are stopped if `:maxT` is reached, and their top-level supervisor terminated with reason `:normal`. This threshold is technically valid in any resource file, but it is only effective for applications with a callback module. Defaults to `:infinity`.

Besides the options above, `.app` files also expect other options like `:modules` and `:vsn`, but these are automatically added by Mix. The complete list can be found on Erlang's application specification.

## Command line options

- `--force` - forces compilation regardless of modification times
- `--compile-path` - where to find `.beam` files and write the resulting `.app` file, defaults to `Mix.Project.compile_path/0`

## Phases

Applications provide a start phases mechanism which will be called, in order, for the application and all included applications. If a phase is not defined for an included application, that application is skipped.

Let's see an example `MyApp.application/0` function:

    def application do
      [
        start_phases: [init: [], go: [], finish: []],
        included_applications: [:my_included_app]
      ]
    end

And an example `:my_included_app` defines on its `mix.exs` the function:

    def application do
      [
        mod: {MyIncludedApp, []},
        start_phases: [go: []]
      ]
    end

In this example, the order that the application callbacks are called in is:

    Application.start(MyApp)
    MyApp.start(:normal, [])
    MyApp.start_phase(:init, :normal, [])
    MyApp.start_phase(:go, :normal, [])
    MyIncludedApp.start_phase(:go, :normal, [])
    MyApp.start_phase(:finish, :normal, [])