stone — interface description language (IDL) for APIs
stone [-h] [-v] [--clean-build] [-f
FILTER_BY_ROUTE_ATTR] [-r
ROUTE_WHITELIST_FILTER] [-a ATTRIBUTE]
[-w WHITELIST_NAMESPACE_ROUTES] [-b
BLACKLIST_NAMESPACE_ROUTES] [backend]
[output] [spec ...]
This manual page documents briefly the stone command.
This manual page was written for the Debian distribution
because the original program does not have a manual page.
stone is a code generator, used to translate your
specification into objects and functions in the programming languages of
your choice.
This program follows the usual GNU command line syntax, with long
options starting with two dashes (`-'). A summary of options is included
below.
- -h --help
- Show help message and exit.
- -v --verbose
- Print debugging statements.
-
--clean-build
- Remove build_path before source files are compiled into them.
- -f
--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
- 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
- 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
- If set, backends will only see the specified namespaces as having
routes.
- -b
--blacklist-namespace-routes
- If set, backends will not see any routes for the specified
namespaces.
- 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.
This manual page was written by fladi fladi@debian.org for the
Debian system (and may be used by others). Permission is granted to
copy, distribute and/or modify this document under the terms of the GNU
General Public License, Version 2 any later version published by the Free
Software Foundation.
On Debian systems, the complete text of the GNU General Public
License can be found in /usr/share/common-licenses/GPL.