Scroll to navigation

STONE(1) General Commands Manual STONE(1)

NAME

stone — interface description language (IDL) for APIs

SYNOPSIS

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 ...]

DESCRIPTION

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.

OPTIONS

This program follows the usual GNU command line syntax, with long options starting with two dashes (`-'). A summary of options is included below.

Show help message and exit.
Print debugging statements.
Remove build_path before source files are compiled into them.
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.
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.
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.
If set, backends will only see the specified namespaces as having routes.
If set, backends will not see any routes for the specified namespaces.

ARGUMENTS

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.
The folder to save generated files to.
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.

AUTHOR

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.