stone — interface description language (IDL) for APIs

       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.

                                                                                                        STONE(1)

       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.

       stone — interface description language (IDL) for APIs

       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.

stone [-h]  [-v]  [--clean-build]  [-fFILTER_BY_ROUTE_ATTR][-rROUTE_WHITELIST_FILTER][-aATTRIBUTE][-wWHITELIST_NAMESPACE_ROUTES][-bBLACKLIST_NAMESPACE_ROUTES][backend]  [output]  [spec ...]