View Source mix compile.app (Mix v1.11.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 indeps/0
in yourmix.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 nameMyServer
, it is recommended to addMyServer
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 theApplication
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 theApplication
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.
Command line options
--force
- forces compilation regardless of modification times--compile-path
- where to find.beam
files and write the resulting.app
file, defaults toMix.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, [])