1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
<!doctype refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!-- Process this file with docbook-to-man to generate an nroff manual
page: `docbook-to-man manpage.sgml > manpage.1'. You may view
the manual page with: `docbook-to-man manpage.sgml | nroff -man |
less'. A typical entry in a Makefile or Makefile.am is:
manpage.1: manpage.sgml
docbook-to-man $< > $@
The docbook-to-man binary is found in the docbook-to-man package.
Please remember that if you create the nroff version in one of the
debian/rules file targets (such as build), you will need to include
docbook-to-man in your Build-Depends control field.
-->
<!-- Fill in your name for FIRSTNAME and SURNAME. -->
<!ENTITY dhfirstname "<firstname>Michael</firstname>">
<!ENTITY dhsurname "<surname>Fladischer</surname>">
<!-- Please adjust the date whenever revising the manpage. -->
<!ENTITY dhdate "<date>25 October 2021</date>">
<!-- SECTION should be 1-8, maybe w/ subsection other parameters are
allowed: see man(7), man(1). -->
<!ENTITY dhsection "<manvolnum>1</manvolnum>">
<!ENTITY dhemail "<email>fladi@debian.org</email>">
<!ENTITY dhusername "fladi">
<!ENTITY dhucpackage "<refentrytitle>STONE</refentrytitle>">
<!ENTITY dhpackage "stone">
<!ENTITY debian "<productname>Debian</productname>">
<!ENTITY gnu "<acronym>GNU</acronym>">
<!ENTITY gpl "&gnu; <acronym>GPL</acronym>">
]>
<refentry>
<refentryinfo>
<address>
&dhemail;
</address>
<author>
&dhfirstname;
&dhsurname;
</author>
<copyright>
<year>2021</year>
<holder>&dhusername;</holder>
</copyright>
&dhdate;
</refentryinfo>
<refmeta>
&dhucpackage;
&dhsection;
</refmeta>
<refnamediv>
<refname>&dhpackage;</refname>
<refpurpose>interface description language (IDL) for APIs</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>&dhpackage;</command>
<arg><option>-h</option></arg>
<arg><option>-v</option></arg>
<arg><option>--clean-build</option></arg>
<arg><option>-f <replaceable>FILTER_BY_ROUTE_ATTR</replaceable></option></arg>
<arg><option>-r <replaceable>ROUTE_WHITELIST_FILTER</replaceable></option></arg>
<arg><option>-a <replaceable>ATTRIBUTE</replaceable></option></arg>
<arg><option>-w <replaceable>WHITELIST_NAMESPACE_ROUTES</replaceable></option></arg>
<arg><option>-b <replaceable>BLACKLIST_NAMESPACE_ROUTES</replaceable></option></arg>
<arg><replaceable>backend</replaceable></arg>
<arg><replaceable>output</replaceable></arg>
<arg rep='repeat'><replaceable>spec</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>DESCRIPTION</title>
<para>This manual page documents briefly the
<command>&dhpackage;</command> command.</para>
<para>This manual page was written for the &debian; distribution
because the original program does not have a manual page.</para>
<para><command>&dhpackage;</command> is a code generator, used to translate
your specification into objects and functions in the programming languages
of your choice.</para>
</refsect1>
<refsect1>
<title>OPTIONS</title>
<para>This program follows the usual &gnu; command line syntax,
with long options starting with two dashes (`-'). A summary of
options is included below.</para>
<variablelist>
<varlistentry>
<term>
<option>-h</option>
<option>--help</option>
</term>
<listitem>
<para>Show help message and exit.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-v</option>
<option>--verbose</option>
</term>
<listitem>
<para>Print debugging statements.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>--clean-build</option>
</term>
<listitem>
<para>Remove build_path before source files are compiled into
them.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-f</option>
<option>--filter-by-route-attr</option>
</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-r</option>
<option>--route-whitelist-filter</option>
</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-a</option>
<option>--attribute</option>
</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-w</option>
<option>--whitelist-namespace-routes</option>
</term>
<listitem>
<para>If set, backends will only see the specified namespaces as having routes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<option>-b</option>
<option>--blacklist-namespace-routes</option>
</term>
<listitem>
<para>If set, backends will not see any routes for the specified namespaces.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>ARGUMENTS</title>
<variablelist>
<varlistentry>
<term>backend</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>output</term>
<listitem>
<para>The folder to save generated files to.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>spec</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>AUTHOR</title>
<para>This manual page was written by &dhusername; &dhemail; 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.
</para>
<para>
On Debian systems, the complete text of the GNU General Public
License can be found in /usr/share/common-licenses/GPL.
</para>
</refsect1>
</refentry>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
|
