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 thestone 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 ofoptions 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 intothem.

-f --filter-by-route-attr

Removes routes that do not match the expression. The expressionmust specify a route attribute on the left-hand side and a value onthe right-hand side. Use quotes for strings and bytes. The onlysupported operators are "=" and "!=". For example, if "hide" is aroute attribute, we can use this filter: "hide!=true". You can combinemultiple expressions with "and"/"or" and use parentheses to enforceprecedence.

-r --route-whitelist-filter

Restrict datatype generation to only the routes specified in thewhitelist and their dependencies. Input should be a file containing aJSON dict with the following form: {"route_whitelist": {},"datatype_whitelist": {}} where each object maps namespaces to listsof routes or datatypes to whitelist.

-a --attribute

Route attributes that the backend will have access to andpresumably expose in generated code. Use ":all" to select allattributes 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.

ARGUMENTS¶

backend

Either the name of a built-in backend or the path to abackend module. Paths to backend modules must end with astoneg.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 .stoneextension. If omitted or set to "-", the spec is read fromstdin. Multiple namespaces can be provided over stdin byconcatenating multiple specs together.

AUTHOR¶

This manual page was written by fladi fladi@debian.org forthe 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 PublicLicense can be found in /usr/share/common-licenses/GPL.