usage: stone [-h] [--version] [-v] [--output-manifest]
             [--expected-output-manifest EXPECTED_OUTPUT_MANIFEST] [--recursive] [--clean-build]
             [-f FILTER_BY_ROUTE_ATTR] [-r ROUTE_WHITELIST_FILTER] [-a ATTRIBUTE]
             [-w WHITELIST_NAMESPACE_ROUTES | -b BLACKLIST_NAMESPACE_ROUTES]
             backend output [spec ...]

Write your APIs in Stone. Use backends to translate your specification into a target language or
format. The following describes arguments to the Stone CLI. To specify arguments that are specific
to a backend, add "--" followed by arguments. For example, "stone python_client . example.spec --
-h".

positional arguments:
  backend               Either the name of a built-in backend or the path to a backend module.
                        Paths to backend modules must end with a .stoneg.py extension. The
                        following backends are built-in: obj_c_client, obj_c_types, obj_c_tests,
                        js_client, js_types, tsd_client, tsd_types, python_types,
                        python_type_stubs, python_client, swift_types, swift_client
  output                The folder to save generated files to.
  spec                  Path to API specifications. Each must have a .stone extension. If omitted
                        or set to "-", the spec is read from stdin. Multiple namespaces can be
                        provided over stdin by concatenating multiple specs together.

options:
  -h, --help            show this help message and exit
  --version             Show the Stone version and exit.
  -v, --verbose         Print debugging statements.
  --output-manifest     Print a JSON manifest of generated output paths instead of writing
                        generated source file contents.
  --expected-output-manifest EXPECTED_OUTPUT_MANIFEST
                        JSON file containing the exact relative output paths Stone must produce.
  --recursive           Recursively expand directory specification arguments into .stone files.
  --clean-build         The path to the template SDK for the target language.
  -f, --filter-by-route-attr FILTER_BY_ROUTE_ATTR
                        Removes routes that do not match the expression. The expression must
                        specify a route attribute on the left-hand side and a value on the right-
                        hand side. Use quotes for strings and bytes. The only supported operators
                        are "=" and "!=". For example, if "hide" is a route attribute, we can use
                        this filter: "hide!=true". You can combine multiple expressions with
                        "and"/"or" and use parentheses to enforce precedence.
  -r, --route-whitelist-filter ROUTE_WHITELIST_FILTER
                        Restrict datatype generation to only the routes specified in the whitelist
                        and their dependencies. Input should be a file containing a JSON dict with
                        the following form: {"route_whitelist": {}, "datatype_whitelist": {}}
                        where each object maps namespaces to lists of routes or datatypes to
                        whitelist.
  -a, --attribute ATTRIBUTE
                        Route attributes that the backend will have access to and presumably
                        expose in generated code. Use ":all" to select all attributes defined in
                        stone_cfg.Route. Note that you can filter (-f) by attributes that are not
                        listed here.
  -w, --whitelist-namespace-routes WHITELIST_NAMESPACE_ROUTES
                        If set, backends will only see the specified namespaces as having routes.
  -b, --blacklist-namespace-routes BLACKLIST_NAMESPACE_ROUTES
                        If set, backends will not see any routes for the specified namespaces.