FFX is divided into some areas of responsibility, with core functionality related to finding and running fuchsia-interacting programs being in the core program (the ffx cli) and the actual programs being built as ‘subtools’ that may either be compiled in with the ffx
cli, or run as external tools (using the FHO subtool interface).
In order to add functionality to be accessible through ffx
, you can write your own subtools and integrate them into the build.
To get started building a simple subtool for ffx
, see developing an ffx subtool.
We also keep a reference implementation of a subtool that does some basic things called ffx-echo
that should always act as a canonical source of how to write a subtool.
If this is the start of a larger project, there are some things you should try to do to make sure your new subtool will work over time:
Writer
for all output related to your subtool. If inclusion in the SDK is expected at some point, make sure that you use a MachineWriter
with a concrete serialize-able type and output works correctly when --machine json
is passed to ffx
.fho::Error
type.ffx
tree, it should have a clear OWNERS
file describing both the team that owns it and individuals who can check CLs against that tool.ffx
tree, but inside the fuchsia.git repository, it must have the ffx owners file
referenced (ie. file:/src/developer/ffx/OWNERS
in its OWNERS file) applying to any files at the api boundary between ffx
and the subtool so that we can make pro-active changes to that api boundary over time.