atomvm

The supported API of one AtomVM release, as data. The package version is the AtomVM version, so a project that depends on it declares which AtomVM it targets, and the build tools check the project against that release instead of against lists of their own.

It contains no modules. Everything is in priv/:

funcs.txt is the union across every platform and library of the release: esp32, rp2, stm32, generic_unix and emscripten functions are all listed, so a project that builds for more than one board is checked once.

Using it

With Elixir, in mix.exs:

defp deps do
  [
    {:exatomvm, github: "atomvm/exatomvm", runtime: false},
    {:atomvm, "~> 0.7.0-alpha.1", runtime: false}
  ]
end

With Erlang, in rebar.config:

{deps, [atomvm]}.

runtime: false keeps the package out of the application list; the build tools leave it out of the packed .avm as well.

For library authors

A library that works with a given AtomVM can say so as ordinary dependency metadata:

{:atomvm, "~> 0.7", optional: true, runtime: false}

Consumers are not forced to take the dependency, but those who pin atomvm themselves get the requirement checked by the resolver, before any AtomVM task runs.

Reading it from your own tool

Dir = code:priv_dir(atomvm),
{ok, Version} = application:get_key(atomvm, vsn),
{ok, Funcs} = file:read_file(filename:join(Dir, "funcs.txt")).

The manifest.json schema grows by adding keys; read the ones you know and ignore the rest.

About this version

0.7.0-alpha.1 was released before the supported API files were generated by the build, so this package was produced afterwards from the v0.7.0-alpha.1 sources. Its funcs.txt is the union of the exports of the release's libraries and of the functions its C sources register natively, which at this version is wider than the exports alone: functions such as Elixir.Esp.ADC:init/0 are callable although no Erlang module exports them. Releases from 0.7.0 on generate the same files from the build itself.