.\" Automatically generated by Pandoc 3.1.3
.\"
.\" Define V font for inline verbatim, using C font in formats
.\" that render this, and otherwise B font.
.ie "\f[CB]x\f[]"x" \{\
. ftr V B
. ftr VI BI
. ftr VB B
. ftr VBI BI
.\}
.el \{\
. ftr V CR
. ftr VI CI
. ftr VB CB
. ftr VBI CBI
.\}
.TH "YOTTA" "1" "December 2018" "0.20.5" "User Commands"
.hy
.SH NAME
.PP
\f[B]yotta\f[R] - build system for C/C++ projects focussed on reusable
components
.SH SYNOPSIS
.PP
\f[B]yotta\f[R] [\f[B]GLOBAL_OPTION\f[R]] \f[B]COMMAND\f[R]
[\f[B]OPTION\f[R]]
.PP
\f[B]yotta\f[R] [\f[B]COMMAND\f[R]] \f[B]--help\f[R]
.PP
\f[B]yotta\f[R] \f[B]--version\f[R]
.SH DESCRIPTION
.PP
\f[B]yotta\f[R] is a build system designed to help developers build
better software for C-family languages by making it easier to share and
re-use software modules.
.PP
\f[B]yotta\f[R] supports project compilation with different compilers by
specifying \f[I]targets\f[R] for compilation.
Each compilation \f[I]target\f[R] can have its own specific
requirements.
.SH OPTIONS
.PP
\f[B]yotta\f[R] supports both \f[I]global arguments\f[R] (that work for
all \f[B]yotta\f[R] commands) and \f[I]command-specific options\f[R].
.TP
[GLOBAL_OPTION] COMMAND [OPTION]
run the specified COMMAND with the optional global and command-specific
options
.TP
[COMMAND] --help
when no command is given, display help for \f[B]yotta\f[R], including a
list of subcommands; when an optional command is given, display help for
the specified subcommand
.TP
--version
display the current version and exit
.SH GLOBAL OPTIONS
.PP
\f[B]yotta\f[R] supports the following global arguments for all
\f[I]commands\f[R] listed below:
.TP
--plain \f[I]subcommand\f[R]
don\[cq]t use coloured output
.TP
--noninteractive \f[I]subcommand\f[R]
don\[cq]t wait for user input
.TP
--target \f[I]targetname\f[R]
override currently-set target for this command (useful when isolating
several instances of \f[B]yotta\f[R])
.TP
--config \f[I]configfile|JSON\f[R]
override target and application-defined configuration; this is useful in
CI infrastructure to easily change the configuration for a particular
build
.SH MODULES
.PP
\f[B]yotta\f[R] can use two types of modules:
.PP
\f[I]Library Modules\f[R]
.PD 0
.P
.PD
\f[I]Executable Modules\f[R]
.SS Library Modules
.PP
Library modules are reusable code, which provide functionality useful to
lots of different apps such as network stacks, drivers and
encoders/decoders.
Anyone can publish a library module to the \f[B]yotta registry\f[R]
where other people can find useful modules and reuse them.
.SS Executable Modules
.PP
Executable modules compile into a binary.
Executable modules should not generally be published to the \f[B]yotta
registry\f[R] because they cannot be reused by other applications, and
instead are typically made available on code-hosting sites such as
Gitlab and Github.
.SH TARGETS
.PP
Targets describe which platform you are building for, and how the
compiler should be run.
.SH SEMANTIC VERSIONING
.PP
\f[B]yotta\f[R] modules use semantic versioning.
A 0.x.y version number indicates a module that does not yet have a
stable API.
When the API is stable the version number is incremented to 1.0.0.
.PP
For modules with a major version >= 1, the major version number must be
incremented whenever backwards-incompatible changes are made.
The minor and patch versions are used for new backwards-compatible
features and bug-fixes respectively.
.SH COMMANDS
.SS init
.IP
.nf
\f[C]
yotta init
\f[R]
.fi
.PP
Create a new \f[V]module.json\f[R] module-description file based on a
set of questions.
If a \f[V]module.json\f[R] file already exists, the values in it will be
used as defaults, and it will not delete anything from the file.
.SS build
.IP
.nf
\f[C]
yotta build [--generate-only] [--debug-build] [--cmake-generator <cmake-generator-name>] [name ... ]
yotta build [ ... ] -- [ build-tool arguments ]
\f[R]
.fi
.PP
Build the current module and its dependencies.
Missing dependencies will be automatically installed first.
.PP
If no \f[V]name\f[R] arguments are specified then the current
module\[cq]s tests will be built, but not the tests for any other
module.
Use \f[V]yotta build all_tests\f[R] to build the tests for all
dependency modules.
.PP
\f[B]yotta\f[R] uses CMake to control the build.
The basic process is:
.IP "1." 3
\f[B]yotta\f[R] installs the target description for the build target
.IP "2." 3
\f[B]yotta\f[R] installs all module dependencies (which may depend on
which target is being built for)
.IP "3." 3
\f[B]yotta\f[R] generates CMakeLists.txt describing the libraries and
executables to build
.IP "4." 3
\f[B]yotta\f[R] instructs CMake to generate the make files / ninja files
/ IDE project file (depending on \f[V]--cmake-generator\f[R])
.IP "5." 3
\f[B]yotta\f[R] instructs CMake to execute the build.
The compiler used depends on the CMake Toolchain file provided by the
active \f[V]yotta target\f[R].
.PP
For more information on the \f[B]yotta\f[R] build process, see the build
system reference.
.PP
\f[B]Options\f[R]
.TP
--generate-only, -g
only generate CMakeLists, don\[cq]t build
.TP
--debug-build, -d
build a debug (less-optimised) build.
The effects depend on the target (this selects CMake build type
\f[V]Debug\f[R]), but generally this means no optimisation, and
\f[V]NDEBUG\f[R] is not defined.
.TP
--release-build, -r
build a release (optimised) build (\f[I]deprecated\f[R]).
The effects depend on the target (this selects CMake build type
\f[V]RelWithDebInfo\f[R]).
This option is deprecated because it is now the default, unless
\f[V]--debug-build\f[R] is specified.
.TP
--cmake-generator, -G
specify the CMake Generator.
CMake can generate project files for various editors and IDEs
.TP
name \&...
one or more modules may be specified, in which case only these modules
and their dependencies will be built.
Use \f[V]all_tests\f[R] to cause all tests to be built.
.TP
-- option1, option2, \&...
any options specified after \f[V]--\f[R] are passed unmodified on to the
tool being used for building (e.g.\ Ninja, or make)
.PP
\f[B]Generating IDE Project Files\f[R]
.PP
The \f[V]-G\f[R]/\f[V]--cmake-generator\f[R] option can be used to
generate project files for various IDE and text editors.
This option is passed through to CMake, but note that only IDE project
files which use Ninja or Makefile build systems will correctly support
cross-compilation for \f[B]yotta\f[R] targets.
.PP
To see the CMake generators available on your platform see
\f[V]cmake --help\f[R].
.PP
\f[B]Examples\f[R]
.PP
Build this module and its tests:
.IP
.nf
\f[C]
yotta build
\f[R]
.fi
.PP
Build the tests for all dependencies:
.IP
.nf
\f[C]
yotta build -d all_tests
\f[R]
.fi
.PP
Generate IDE project files:
.IP
.nf
\f[C]
yotta build -d -G \[dq]Sublime Text 2 - Ninja\[dq]
yotta build -d -G \[dq]Eclipse CDT4 - Ninja\[dq]
\f[R]
.fi
.PP
Pass options through to the build system:
.IP
.nf
\f[C]
yotta build -G \[dq]Unix Makefiles\[dq] -- -j 4
yotta build -- -v
\f[R]
.fi
.SS search
.IP
.nf
\f[C]
yotta search <string> [--keyword=<keyword>] [--limit=<N>]
yotta search module <string> [--keyword=<keyword>] [--limit=<N>]
yotta search target <string> [--keyword=<keyword>] [--limit=<N>]
\f[R]
.fi
.PP
Search for open-source \f[B]yotta\f[R] modules and build targets that
have been published to the \f[B]yotta registry\f[R].
.PP
The results will be listed in combined order of search relevance and
popularity.
.PP
\f[B]Options\f[R]
.TP
--keyword, -k
specify keywords to constrain the search (use multiple times for
multiple keywords, modules returned will have all of the specified
keywords)
.TP
--limit, -l
limit the number of results returned
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
yotta search logging
yotta search module logging
yotta search target -k mbed-official -k mbed-target:k64f
\f[R]
.fi
.SS test
.IP
.nf
\f[C]
yotta test [--list] [--no-build] [ build-arguments ] [tests-to-run ...]
\f[R]
.fi
.PP
Run tests.
If no arguments are specified, then the tests for the current module
will be run, use \f[V]yotta test all\f[R] to run the tests for all
modules.
.PP
The target description provides support for the test command if it is a
cross-compiling target (no support is necessary to run tests natively).
.PP
The \f[V]scripts.test\f[R] value in the target description is executed
with \f[V]$program\f[R] expanded to the path to the binary, it should be
a wrapper script that loads the binary at the specified path onto the
target device, runs it, and prints output on standard output.
.PP
\f[B]Options\f[R]
.TP
--list, -l
list the tests that would be run, rather than running them.
Implies \f[V]--no-build\f[R].
.TP
--no-build, -n
don\[cq]t build anything, try to run already-built tests.
Things will fail if all the specified tests are not built!
.PP
This command also accepts the options to \f[V]yotta build\f[R], which
are used if building.
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
yotta test
yotta test --list all
yotta test -n my-test
yotta test --config=\[dq]path/to/test-config.json\[dq]
\f[R]
.fi
.SS debug
.IP
.nf
\f[C]
yotta debug <program>
\f[R]
.fi
.PP
If the target description supports it, launch a debugger attached to the
specified executable.
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
yotta debug test/simplelog-test
yotta debug source/helloyotta
\f[R]
.fi
.SS target
.IP
.nf
\f[C]
yotta target
yotta target <targetname>[\[at]url-or-version-spec] [-g] [-n]
\f[R]
.fi
.PP
Display or set the current target.
\f[B]yotta\f[R] will look for and install a target description from the
\f[B]yotta registry\f[R] when building or installing dependencies.
If you run \f[V]yotta target\f[R] in an existing module \f[B]yotta\f[R]
will attempt to download the target description immediately, unless
\f[V]-n\f[R] is specified.
.PP
Targets define the options and commands that \f[B]yotta\f[R] uses to
compile modules and executables.
.PP
A target must define a CMake Toolchain file describing all of the rules
that \f[B]yotta\f[R] uses to build software; it may also define commands
to launch a debugger (used by \f[V]yotta debug\f[R]).
.PP
If \f[V]-g\f[R] is specified when setting the target, it will be saved
globally (in the user settings file).
Otherwise the specified target will be saved for the current module
only, in a \f[V].yotta.json\f[R] file.
.PP
If the target is set both locally and globally, the locally-set target
takes precedence.
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
yotta target x86-osx-native
yotta target frdm-k64f-gcc\[at]\[ha]2.0.0
\f[R]
.fi
.SS install
.PP
Synonyms: \f[V]yotta in\f[R]
.IP
.nf
\f[C]
# in a module directory:
yotta install
yotta install <module>[\[at]<version>]

# GitHub usage
yotta install <username>/<reponame>
yotta install <username>/<reponame>#<version|tagname|branchname|commit>

# anywhere:
yotta install <module>[\[at]<version>] [--global]
\f[R]
.fi
.PP
Install a module, including the modules that it depends on.
.PP
Typical usage is:
.IP
.nf
\f[C]
yotta install <module>
\f[R]
.fi
.PP
which installs \f[V]<module>\f[R] and its dependencies, and saves it in
the current module\[cq]s description file.
.PP
A \f[V]<module>\f[R] is one of:
.IP \[bu] 2
a name, in which case the module is installed from the public \f[B]yotta
registry\f[R] (https://yottabuild.org)
.IP \[bu] 2
a github spec (username/reponame), in which case the module is installed
directly from github.
This can include private github URLs.
.PP
\f[B]yotta install (no arguments, in a module folder)\f[R]
.PP
In a module directory, \f[V]yotta install\f[R] will check for and
install any missing dependencies of the current module.
.PP
Options:
.TP
--install-linked
also traverse into any linked modules, and install their dependencies.
By default linked modules are not modified.
Note that without this option all the required dependencies to build may
not be installed.
.PP
\f[B]yotta install (in a module folder)\f[R]
.PP
In a module directory, \f[V]yotta install <module>\f[R] will install the
specified module, and any missing dependencies for it.
.PP
The installed version of the module will be saved as a dependency into
the current module\[cq]s module.json file.
This uses the \f[V]\[ha]\f[R] semantic-version specifier to specify that
only minor version updates are allowed to be installed, \f[B]unless\f[R]
the module has a 0.x.x version number, in which case the \f[V]\[ti]\f[R]
semantic-version specifier is used restrict updates to patch versions
only.
.PP
\f[B]yotta install /\f[R]
.PP
Install the specified module and any missing dependencies in a similar
manner to above, using GitHub as the source.
.PP
When a version isn\[cq]t specified, \f[B]yotta\f[R] will attempt to
select the latest release version from the tags available on the
repository.
If none are found, the master branch will be installed.
.PP
\f[B]yotta install /#<version|tagname|branchname|commit>\f[R]
.PP
Install the specified module and any missing dependencies in a similar
manner to above, using GitHub as the source.
.PP
An optional version specification (which tries to match repository tags
using semver), tag name, branch name or commit ID can be specified to
install the repository using that marker.
.PP
\f[B]yotta install (anywhere)\f[R]
.PP
Download the specified dependency, and install it in a subdirectory of
the current directory.
.PP
Options:
.TP
--global
install the specified module into the global modules directory instead.
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
yotta install simpleog
yotta install ARM-RD/simplelog
\f[R]
.fi
.SS update
.PP
Synonyms: \f[V]yotta up\f[R]
.IP
.nf
\f[C]
yotta update
yotta update <module>
\f[R]
.fi
.PP
Update all of the current modules dependencies to the latest matching
versions.
Or, if a module is specified, update only that module and its
dependencies.
.PP
\f[B]Options\f[R]
.TP
--update-linked
update the dependencies of linked modules too.
.SS version
.PP
Synonyms: \f[V]yotta v\f[R]
.IP
.nf
\f[C]
yotta version [patch | minor | major | <version>]
\f[R]
.fi
.PP
Bump the current module\[cq]s version, set a new version, or display the
current version.
\f[V]patch\f[R], \f[V]minor\f[R] and \f[V]major\f[R] declare which part
of the major.minor.patch version number to bump.
.PP
If the current module is version-controlled by mercurial or git, then
the new version is tagged.
If the module is version controlled but the working directory is not
clean, then an error message is printed.
.SS login
.IP
.nf
\f[C]
yotta login
\f[R]
.fi
.PP
Authenticate with the \f[B]yotta registry\f[R].
\f[B]yotta\f[R] will open a browser to an OAuth login page on the
\f[B]yotta registry\f[R], where you can then log in with either GitHub
or mbed.
This process generates a secret access token that is saved in your
\f[B]yotta\f[R] configuration file, and which \f[B]yotta\f[R] can use to
pull from private repositories that you have access to on GitHub or
mbed.
.PP
You must log in before you can publish modules.
Access control for publishing is based on email addresses verified by
GitHub/mbed, you can see the email address of the owners with permission
to publish a given module using the \f[V]yotta owners\f[R] command.
.PP
No information other than your email address, and a public key generated
by your \f[B]yotta\f[R] client, is stored by the \f[B]yotta
registry\f[R].
Even someone with access to the \f[B]yotta registry\f[R]\[cq]s database
would not be able to publish modules in your name without stealing
information that never leaves your computer!
.SS logout
.IP
.nf
\f[C]
yotta logout
\f[R]
.fi
.PP
Remove all saved authentication information from the current computer.
Does not revoke access tokens, as GitHub returns the same access token
for each computer that you log into \f[B]yotta\f[R] on.
If you wish to revoke access tokens you can do so on your GitHub account
page.
.SS whoami
.IP
.nf
\f[C]
yotta whoami
yotta who
\f[R]
.fi
.PP
Display the primary email address(es) that you are currently
authenticated to.
If you are not logged in then this will return a non-zero status code,
otherwise the status code is 0.
.PP
\f[B]Examples\f[R]
.IP
.nf
\f[C]
$ yotta whoami
friend\[at]example.com

$ yotta logout
$ yotta whoami
not logged in
\f[R]
.fi
.SS publish
.IP
.nf
\f[C]
yotta publish
\f[R]
.fi
.PP
Publish the current module or target to the public \f[B]yotta
registry\f[R] (https://yottabuild.org), where other people will be able
to search for and install it.
.PP
Any files matching lines in the \f[V].yotta_ignore\f[R] file (if
present) are ignored, and will not be included in the published tarball.
.SS link
.PP
Synonyms: \f[V]yotta ln\f[R]
.IP
.nf
\f[C]
yotta link (in a module directory)
yotta link <modulename>
yotta link /path/to/a/module
\f[R]
.fi
.PP
Module linking allows you to use local versions of modules when building
other modules \[en] it\[cq]s useful when fixing a bug in a dependency
that is most easily reproduced when that dependency is used by another
module.
.PP
To link a module there are two steps.
First, in the directory of the dependency:
.IP
.nf
\f[C]
yotta link
\f[R]
.fi
.PP
This will create a symlink from the global modules directory to the
current module.
.PP
Then, in the module that you would like to use the linked version of the
dependency, run:
.IP
.nf
\f[C]
yotta link <depended-on-module-name>
\f[R]
.fi
.PP
When you run \f[V]yotta build\f[R] it will then pick up the linked
module.
.PP
This works for direct and indirect dependencies: you can link to a
module that your module does not use directly, but a dependency of your
module does.
.PP
The variant of the command which takes a path to an existing module
(e.g.\ \f[V]yotta link ../path/to/a/module\f[R]) performs both steps in
sequence, for convenience.
.PP
\f[B]Directories\f[R]
.PP
When you run \f[V]yotta link\f[R], links are created in a system-wide
directory under \f[V]YOTTA_PREFIX\f[R], and the links in that directory
are then picked up by subsequent \f[V]yotta link <modulename>\f[R]
commands.
.PP
On Linux this defaults to \f[V]/usr/local\f[R].
To change this directory (e.g.\ to make \f[B]yotta\f[R] link things into
your home directory), set the \f[V]YOTTA_PREFIX\f[R] environment
variable.
.SS link-target
.IP
.nf
\f[C]
yotta link-target (in a target directory)
yotta link-target <targetename>
yotta link-target /path/to/a/target
\f[R]
.fi
.PP
To link a target you need to perform two steps.
First, in the directory of the target:
.IP
.nf
\f[C]
yotta link-target
\f[R]
.fi
.PP
This will create a symlink from the global targets directory to the
current target.
.PP
Then, in the module that you would like to use the linked version of the
target, run:
.IP
.nf
\f[C]
yotta link-target <targetename>
\f[R]
.fi
.PP
When you run \f[V]yotta build\f[R] (provided you\[cq]ve set
\f[V]yotta target\f[R] to \f[V]<targetname>\f[R]), the linked target
description will be used.
.PP
The variant of the command which takes a path to an existing module
(e.g.\ \f[V]yotta link ../path/to/a/module\f[R]) performs both steps in
sequence, for convenience.
.PP
See also \f[V]yotta link\f[R].
.SS list
.PP
Synonyms: \f[V]yotta ls\f[R]
.IP
.nf
\f[C]
yotta list [--all]
yotta list [--json]
\f[R]
.fi
.PP
List the installed dependencies of the current module, including
information on the installed versions.
Unless \f[V]--all\f[R] is specified, dependencies are only listed under
the modules that first use them, with \f[V]--all\f[R] dependencies that
are used my multiple modules are listed multiple times (but all modules
will use the same installed instance of the dependency).
.PP
The \f[V]--json\f[R] option will cause the list to be output in JSON
format, for example:
.IP
.nf
\f[C]
{
  \[dq]modules\[dq]: [
    {
      \[dq]name\[dq]: \[dq]toplevel-module-name\[dq],
      \[dq]version\[dq]: \[dq]1.0.0\[dq],
      \[dq]path\[dq]: \[dq]/some/path/on/disk/toplevel-module-name\[dq],
      \[dq]specifications\[dq]: [
        {
          \[dq]version\[dq]: \[dq]\[ti]0.11.0\[dq],
          \[dq]name\[dq]: \[dq]some-dependency-name\[dq]
        }
      ]
    },
    {
      \[dq]name\[dq]: \[dq]some-dependency-name\[dq],
      \[dq]version\[dq]: \[dq]0.11.7\[dq],
      \[dq]path\[dq]: \[dq]/some/path/on/disk/yotta_modules/some-dependency-name\[dq],
      \[dq]linkedTo\[dq]: \[dq]/some/path/on/disk/some-dependency-name\[dq],
      \[dq]specifications\[dq]: [
        {
          \[dq]version\[dq]: \[dq]ARMmbed/some-test-dependency#\[ha]1.2.3\[dq],
          \[dq]name\[dq]: \[dq]some-test-dependency\[dq],
          \[dq]testOnly\[dq]: true
        }
      ]
    },
    {
      \[dq]name\[dq]: \[dq]some-test-dependency\[dq],
      \[dq]version\[dq]: \[dq]1.5.6\[dq],
      \[dq]path\[dq]: \[dq]/some/path/on/disk/yotta_modules/some-test-dependency\[dq],
      \[dq]errors\[dq]: [
        \[dq]a description of some error with this module\[dq]
      ]
    }
}
\f[R]
.fi
.SS uninstall
.PP
Synonyms: \f[V]yotta unlink\f[R], \f[V]yotta rm\f[R], \f[V]yotta un\f[R]
.IP
.nf
\f[C]
yotta uninstall <module>
\f[R]
.fi
.PP
Remove the specified dependency of the current module (or destroy the
symlink if it was linked).
.SS owners
.PP
Synonyms: \f[V]yotta owner\f[R]
.IP
.nf
\f[C]
yotta owners list [<modulename>]
yotta owner add <email> [<modulename>]
yotta owner remove <email> [<modulename>]
\f[R]
.fi
.PP
List, add, or remove owners from the specified module or target.
Owners are people with permission to publish new versions of a module,
and to add/remove other owners.
.PP
If the current directory is a module or target, then the module name is
optional, and defaults to the current module.
.SS licenses
.IP
.nf
\f[C]
yotta licenses [--all]
\f[R]
.fi
.PP
List the licenses of all of the modules that the current module depends
on.
If \f[V]--all\f[R] is specified, then each unique license is listed for
each module it occurs in, instead of just once.
.PP
\f[B]NOTE:\f[R] while \f[B]yotta\f[R] can list the licenses that modules
have declared in their \f[V]module.json\f[R] files, it can make no
warranties about whether modules contain code under other licenses that
have not been declared.
.SS config
.IP
.nf
\f[C]
yotta config
\f[R]
.fi
.PP
Display the merged config data for the current target (and application,
if the current module defines an executable application).
.PP
The config data is produced by merging the json config data defined by
the application, the current target, and any targets the current target
inherits from recursively.
Values defined by the application will override those defined at the
same path by targets, and values defined in targets will override values
defined by targets they inherit from.
.PP
The config data displayed is identical to the data that will be
available to modules when they are built.
.PP
See the \f[V]yotta config\f[R] system reference for more details.
.SS outdated
.IP
.nf
\f[C]
yotta outdated
\f[R]
.fi
.PP
List modules for which newer versions are available from the \f[B]yotta
registry\f[R].
.SS shrinkwrap
.IP
.nf
\f[C]
yotta shrinkwrap
\f[R]
.fi
.PP
Create a \f[V]yotta-shrinkwrap.json\f[R] file in the current module,
which specifies the exact versions of dependencies and target
descriptions currently being used.
.PP
When a module with a \f[V]yotta-shrinkwrap.json\f[R] file is installed,
the versions specified in the shrinkwrap will be downloaded from the
public \f[B]yotta registry\f[R], instead of the latest versions that
satisfy the specifications from module.json files.
\f[B]When a shrinkwrap file is present, dependencies will always be
downloaded from the registry, not from git/other URLs.\f[R]
.PP
In practise this allows an application or module to specify a known-good
set of dependencies that it should be used with.
.PP
Note that generally publishing modules with a
\f[V]yotta-shrinkwrap.json\f[R] file to the \f[B]yotta registry\f[R]
should be avoided.
The exact versions specified in the shrink-wrap could easily cause
version conflicts with other modules which depend on the same modules.
.PP
The format of the \f[V]yotta-shrinkwrap.json\f[R] file is:
.IP
.nf
\f[C]
{
  \[dq]modules\[dq]: [
    {
      \[dq]version\[dq]: \[dq]1.0.0\[dq],
      \[dq]name\[dq]: \[dq]first-module-name\[dq]
    },
    {
      \[dq]version\[dq]: \[dq]0.11.7\[dq],
      \[dq]name\[dq]: \[dq]a-dependency-name\[dq]
    },
    ...
  ],
  \[dq]targets\[dq]: [
   {
     \[dq]version\[dq]: \[dq]1.2.3\[dq],
     \[dq]name\[dq]: \[dq]some-target-name\[dq]
   },
   ...
  ]
}
\f[R]
.fi
.SH FILES
.PP
yotta targets:
.PP
\f[B]target.json\f[R]
.PD 0
.P
.PD
\f[B].yotta_ignore\f[R]
.PD 0
.P
.PD
\f[B].yotta.json\f[R]
.PP
yotta modules:
.PP
\f[B]config.json\f[R]
.PD 0
.P
.PD
\f[B]module.json\f[R]
.PD 0
.P
.PD
\f[B].yotta_ignore\f[R]
.PD 0
.P
.PD
\f[B].yotta.json\f[R]
.SH ENVIRONMENT VARIABLES
.PP
\f[B]yotta\f[R] behaviour can be customised using the following
environment variables:
.PP
\f[B]YOTTA_PREFIX\f[R]
.PP
\f[B]YOTTA_GITHUB_AUTHTOKEN\f[R]
.SH REPORTING BUGS
.PP
Upstream bug tracker: https://github.com/ARMmbed/yotta/issues
.SH COPYRIGHT
.PP
Copyright (c) 2014-15 ARM Limited
.SH AUTHOR
.PP
This manual page is based on the yotta command reference.
It was created by Nick Morrott <nickm@debian.org> for the Debian
GNU/Linux system, but may be used by others
.SH SEE ALSO
.PP
\f[B]mbed_test_wrapper\f[R](1), \f[B]mbedhtrun\f[R](1),
\f[B]mbedls\f[R](1), \f[B]valinor\f[R](1), \f[B]progen\f[R](1),
\f[B]progendef\f[R](1)