View Source Environment variables

Nerves uses environment variables to control the build process and pass options to cross-compilers.

Overridable variables

Set these variables if you would like to adjust how Nerves builds device-specific code.

Nerves-provided environment variables

Nerves sets the environment variables in this section to control compilation. Most variables affect the compilation of C and C++ code so that they use the right crosscompiler, flags, and directories. These environment variables are available to mix, rebar3 and any code invoked from them. For example, these are frequently used in the Makefiles invoked by elixir_make.

Also see the elixir_make documentation for additional environment variables that may be useful.

Target CPU, ARCH, OS, and ABI

The TARGET_* variables are optionally set by the Nerves system. All official Nerves systems set them, but it is not mandatory for forks. These variables are useful for guiding compilation of LLVM-based tools.

The current way of deriving their values is to use zig and to select the combination that makes most sense for the target. To view the options, install zig and run:

zig targets | less

These variables are defined as custom environment variables in the Nerves system's mix.exs. For example, the following is the definition for the Raspberry Pi Zero:

  defp nerves_package do
    [
      type: :system,
      ...
      env: [
        {"TARGET_ARCH", "arm"},
        {"TARGET_CPU", "arm1176jzf_s"},
        {"TARGET_OS", "linux"},
        {"TARGET_ABI", "gnueabihf"}
      ]
      ...
    ]
  end

While the TARGET_* environment variables are mostly geared for non-gcc compilers, it's useful to add custom flags to gcc invocations as well. The TARGET_GCC_FLAGS option supports this. The Nerves tooling will prepend the contents of TARGET_GCC_FLAGS to the CFLAGS and CXXFLAGS used when compiling NIFs and ports. This can be used to enable features like ARM NEON support that would otherwise be off when using crosscompiler toolchain defaults. Most users don't need to concern themselves with TARGET_GCC_FLAGS. If you are creating a custom system, not setting TARGET_GCC_FLAGS is almost always fine, but will result in NIFs and ports being built with generic compiler options.