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
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
|
/****************************************************************************
**
** Copyright (C) 2017 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of Qbs.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\contentspage list-of-language-items.html
\previouspage PropertyOptions
\nextpage Scanner
\qmltype Rule
\inqmlmodule QbsLanguageItems
\ingroup list-of-items
\keyword QML.Rule
\brief Creates transformers for input tags.
In \QBS, rules create \e transformers that produce output files from input files.
The term \e transformer refers to a list of \l{Command and JavaScriptCommand}{commands}.
These commands are created in a rule's \l{prepare} script. They do the actual work, either
directly or by executing external commands.
\section1 A Simple Example
The following rule takes text files and replaces Windows-style line endings with their
Unix-style counterparts. We will look at it one piece at a time.
\quotefromfile ../examples/rule/rule.qbs
\skipto Rule
\printuntil multiplex: false
A \e {multiplex rule} creates one transformer that takes all input artifacts with the
matching input file tag and creates one or more output artifacts. We are setting the
respective property to \c false here, indicating that we want to create one transformer
per input file.
\note This is actually the default, so the above assignment is not required.
\printuntil inputs: ["txt_input"]
Here we are specifying that our rule is interested in input files that have the tag
\c "txt_input". Such files could be source files, in which case you would tag them
using a \l{Group}. Or they could in turn get generated by a different rule,
in which case that rule would assign the file tag.
The files matching the tag will be available in the \l{prepare} script under the name
\c inputs (see \l{inputs and outputs}{The inputs and outputs Variables}).
\printuntil }
Here we are specifying that for every input file, we want to create one output file
whose name is the same as the input file, but with an additional extension. Because we are
giving a relative path, \QBS will prepend that path by the product's build directory.
In addition, we tell \QBS that the output files should get the file tag \c "txt_output". This
enables other rules to use these files as inputs. You must always assign suitable file tags
to your output artifacts, or the rule will not be run.
See \l{Rules and Product Types} for details.
If you want to create more than one output file per input file, you simply provide multiple
\l Artifact items. The set of output artifacts will be available in the prepare script
under the name \c outputs (see \l{inputs and outputs}{The inputs and outputs Variables}).
\printuntil /^\s{4}\}/
The prepare script shown above puts everything together by creating the command that does
the actual transformation of the file contents, employing the help of the
\l{TextFile Service}{TextFile} class.
As you can see, the return value is an array, meaning you can provide several commands to
implement the rule's functionality. For instance, if we had provided two \c Artifact items,
we might have also provided two commands, each of them creating one output file.
For the \c input and \c output variables used in the code, see the next section.
\target inputs and outputs
\section1 The \c inputs and \c outputs Variables
We already mentioned that the input and output artifacts are available in the prepare script
via the variables \c inputs and \c outputs, respectively. These variables are JavaScript
objects whose property keys are file tags and whose property values are lists of objects
representing the artifacts matching these tags. In our example, the \c inputs variable
has a single property \c txt_input, whose value is a list with one element. Similarly, the
\c outputs variable also has one single property \c txt_output, again with a list containing
one element.
The actual artifact objects have the following properties:
\table
\header
\li Property
\li Description
\row
\li \c baseName
\li The file name without any extension.
\row
\li \c completeBaseName
\li The file name without the last extension.
\row
\li \c fileName
\li The name of the file (that is, \c filePath without any directory components).
\row
\li \c filePath
\li The full file path.
\row
\li \c fileTags
\li The list of the artifact's file tags.
\endtable
The artifact object contains a property for every module that is used in the product. That can
be used to access the module's properties. For instance, for an artifact in a C++ product,
\c{artifact.cpp.defines} is the list of defines that will be passed when compiling the
respective file.
But what about the variables \c input and \c output that appeared in our example? These
are simply convenience variables which are available in the case that the \c inputs
and \c outputs variables contain only one artifact, respectively. So in our example, instead
of \c input we also could have written \c {inputs.txt_input[0]}, which is considerably
more verbose.
\section1 Rules and Product Types
It is important to know that when figuring out which rules to execute, \QBS starts at the
product type and then looks for a way to produce artifacts with matching file tags from
source files, using a chain of rules that are connected by their respective input and output
tags. For instance, consider this simple C++ project:
\code
Product {
type: ["application"]
Depends { name: "cpp" }
files: ["main.cpp"]
}
\endcode
Here's how this product is built:
\list 1
\li \QBS looks for a rule that can produce artifacts with the file tag
\c{"application"}. Such a rule is found in the \l{cpp} module
(namely, the rule that invokes the linker).
\li Since the rule found in the previous step takes inputs of type \c{"obj"}, \QBS now
looks for a rule that produces artifacts of that type. Again, such a rule is found in
the \c cpp module (the rule that runs the compiler).
\li The rule found in the previous step takes inputs of type \c{"cpp"}. No rule is found
that creates such artifacts, but we do have a source file with a matching type (because
the \c cpp module contains a \l{FileTagger} which attached that type
to \c{"main.cpp"} due to its file extension).
\li Now that there is a chain of rules leading from a source file tag to the product type,
the commands of these rules are executed one after the other until we end up with
our executable.
\endlist
\section1 A Complete Example
The following code snippet shows a single \l{Rule} within a \l{Product} and summarizes the
previous sections.
\note The product's type is set up to the \c "txt_output" file tag to tell \QBS that the
product depends on output artifacts produced by the custom rule. Otherwise the rule would not
be executed.
\quotefile ../examples/rule/rule.qbs
*/
/*!
\qmlproperty bool Rule::multiplex
Determines whether this is a multiplex rule.
\defaultvalue \c false
*/
/*!
\qmlproperty stringList Rule::inputs
A list of file tags the input artifacts must match.
All output artifacts will depend on all artifacts in the product with
the given input file tags. Also, these artifacts are available in the
\c inputs variable of the \l{prepare} script.
\nodefaultvalue
*/
/*!
\qmlproperty stringList Rule::auxiliaryInputs
A list of file tags. This rule will be dependent on every other rule that
produces artifacts that are compatible with the value of this property.
Unlike \l{inputs}, this property has no effect on the content of the
\c inputs variable of the \l{prepare} script.
All rules in this product and rules of product dependencies that produce
target artifacts are considered.
\nodefaultvalue
*/
/*!
\qmlproperty stringList Rule::excludedInputs
A list of file tags. Connections to rules that produce these file tags are
prevented.
\nodefaultvalue
\since Qbs 1.12
*/
/*!
\qmlproperty stringList Rule::inputsFromDependencies
A list of file tags that the artifacts of product dependencies must match.
For example, the product \a foo might appear as follows in the current
product:
\code
Depends {
name: "foo"
}
\endcode
All artifacts of \a foo that match the given file tags will appear in the
\c inputs variable of the \l{prepare} script.
\nodefaultvalue
*/
/*!
\qmlproperty var Rule::outputArtifacts
An array of output artifacts, specified as JavaScript objects.
For example:
\code
outputArtifacts: [{
filePath: "myfile.cpp",
fileTags: ["cpp"],
cpp: { cxxLanguageVersion: "c++11" }
}]
\endcode
For a description of the possible properties, see the documentation of the
\l{Artifact} item.
Output artifacts can be specified either by this property or by \l{Artifact}
items. Use this property if the set of outputs is not fixed but depends the
input's content. If no file tags are provided, \QBS will apply all
\l{FileTagger}{file taggers} known in the current context to the output file
name.
The user may set the property \c{explicitlyDependsOn} on artifact objects, which is
similar to \l{Rule::explicitlyDependsOn}{Rule.explicitlyDependsOn}.
\nodefaultvalue
*/
/*!
\qmlproperty stringList Rule::outputFileTags
If output artifacts are specified by \l{outputArtifacts}, this property must
specify a list of file tags that the rule potentially produces.
\nodefaultvalue
*/
/*!
\qmlproperty bool Rule::condition
If \c true, the rule is enabled, otherwise it does nothing.
\defaultvalue \c true
*/
/*!
\qmlproperty stringList Rule::explicitlyDependsOn
A list of file tags. Each artifact that matches the file tags is added to
the dependencies of each output node. All artifacts in the current product
are considered.
\nodefaultvalue
*/
/*!
\qmlproperty stringList Rule::explicitlyDependsOnFromDependencies
A list of file tags. Each artifact that matches the file tags is added to
the dependencies of each output node. Only target artifacts of products that this product
depends on are considered.
\nodefaultvalue
\since Qbs 1.12
*/
/*!
\qmlproperty script Rule::prepare
A script that prepares the commands to transform the inputs to outputs.
The code in this script is treated as a function with the signature
\c{function(project, product, inputs, outputs, input, output, explicitlyDependsOn)}.
The argument \c{input} is \c{undefined} if there's more than one input
artifact for this rule. Similarly, \c{output} is only defined if there is
exactly one output artifact.
\nodefaultvalue
*/
/*!
\qmlproperty bool Rule::requiresInputs
Specifies whether a rule's commands should be created even if no inputs are
available.
Enabling this property can be useful if you are not sure whether input
files exist, and you want \QBS to create an output file even if they do not.
Set to \c true if the rule declares any inputs, \c false otherwise.
*/
/*!
\qmlproperty bool Rule::alwaysRun
If \c true, the rule's commands are always executed, even if all output
artifacts are up to date.
\defaultvalue \c false
*/
|