View Source mix compile.app (Mix v1.18.0)

Writes a .app file.

A .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 the :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.

From Elixir v1.17 onwards, the application .app file is also loaded whenever the task runs.

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

Configuration

  • :reliable_dir_mtime - this task relies on the operating system changing the mtime on a directory whenever a file is added or removed. You can set this option to false if your system does not provide reliable mtimes. Defaults to false on Windows.

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, [])