# FIDL: Compiler Interface This document describes the command-line interface to the FIDL compiler. Information on the internals of that tool lives [alongside the source of the tool](../../system/host/fidl/README.md). See [FIDL: Overview](index.md) for more information about FIDL's overall purpose, goals, and requirements, as well as links to related documents. ## Overview The FIDL compiler is split into a frontend and a number of backends. The compiler processes one library at a time. The frontend consumes the FIDL declarations for the library (as well as for all transitive dependencies), performs semantic analysis, and outputs an intermediate representation of the library. The backends consume the intermediate representation and generate language-specific bindings for the library. ## Frontend The frontend is a command-line program named `fidlc`. The `fidlc` compiler takes a number of arguments: * `--c-header HEADER_PATH`. If present, this flag instructs `fidlc` to output a C header at the given path. In principle, the C header generation could have been implemented as a C backend, but for some practical reasons, we integrated the C header generation directly into the frontend. * `--tables TABLES_PATH`. If present, this flag instructs `fidlc` to output coding tables at the given path. The coding tables are required to encode and decode messages from the C and C++ bindings. * `--json JSON_PATH`. If present, this flag instructs `fidlc` to output the library's intermediate representation at the given path. The intermediate representation is JSON that conforms to [a particular schema](../../system/host/fidl/schema.json). The intermediate representation is used as input to the various backends. * `--name LIBRARY_NAME`. If present, this flag instructs `fidlc` to validate that the library being compiled has the given name. This flag is useful to cross-check between the library's declaration in a build system and the actual contents of the library. * `--files [FIDL_FILE...]...`. Each `--file [FIDL_FILE...]` chunk of arguments describes a library, all of which must share the same top-level library name declaration. Libraries must be presented in dependency order, with later libraries able to use declarations from preceding libraries but not vice versa. Output is only generated for the final library, not for each of its dependencies. All of the arguments can also be provided via a response file, denoted as `@responsefile`. The contents of the file at `responsefile` will be interpreted as a whitespace-delimited list of arguments. Response files cannot be nested, and must be the only argument. ## Backend The backend is a command-line program named `fidlgen`. The `fidlgen` compiler takes a number of arguments: * `--json` (required). The path to the intermediate representation of the library. The intermediate representation is JSON that conforms to [a particular schema](../../system/host/fidl/schema.json). * `--generators` (required). A comma-separated list of generators to run on the given library. The following generators are currently supported: `cpp`, `go`, `dart`, and `rust`. * `--output-base` (required). The base file name for files generated by this generator. The generator will create files by adding extensions to this file name. For example, the `cpp` backend generates two files, one with the `.h` extension and another with the `.cc` extension. * `--include-base` (required). The base directory relative to which C and C++ `#include` directives should be computed. For example, when the `cpp` backend generates an `#include` directive to reference the `.h` file from the `.cc` file, the backend will create the `#include` path relative to this directory. ## Limitations For the `cpp` backend, the generated `.h` file must be incluable as `#include `, where `$LIBRARY_NAME` is the name of the corresponding FIDL library. Typically, that means that the `--output-base` flag will have the value `$INCLUDE_BASE/fuchsia/cpp/$LIBRARY_NAME`, where `$INCLUDE_BASE` is the value of the `--include-base` flag.