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
|
/****************************************************************************
**
** Copyright (C) 2015 The Qt Company Ltd.
** Contact: http://www.qt.io/licensing
**
** This file is part of Qbs.
**
** 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 http://www.qt.io/terms-conditions. For further information
** use the contact form at http://www.qt.io/contact-us.
**
** GNU Lesser General Public License Usage
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 2.1 or version 3 as published by the Free
** Software Foundation and appearing in the file LICENSE.LGPLv21 and
** LICENSE.LGPLv3 included in the packaging of this file. Please review the
** following information to ensure the GNU Lesser General Public License
** requirements will be met: https://www.gnu.org/licenses/lgpl.html and
** http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** In addition, as a special exception, The Qt Company gives you certain additional
** rights. These rights are described in The Qt Company LGPL Exception
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
**
****************************************************************************/
/*!
\contentspage list-of-items.html
\previouspage qtapplication-item.html
\page rule-item.html
\nextpage staticlibrary-item.html
\ingroup list-of-items
\title Rule Item
\brief Creates transformers for input tags.
A \e {multiplex rule} creates one \e transformer that takes all
input artifacts with the matching input file tag and creates
one or more artifacts (e.g. C++ linker).
A \e {simplex rule} creates one transformer per matching input file
(e.g. C++ compiler).
For instance, the following rule transforms text files:
\code
Rule {
inputs: ["txt_input"]
Artifact {
filePath: "output.txt"
fileTags: "txt_output"
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "Processing '" + input.filePath + "'";
cmd.highlight = "codegen";
cmd.sourceCode = function() {
var file = new TextFile(input.filePath);
var content = file.readAll();
file.close()
content = content.replace(/\r\n/g, "\n");
file = new TextFile(output.filePath, TextFile.WriteOnly);
file.write(content);
file.close();
}
return cmd;
}
}
\endcode
This example exhibits some interesting features of rules:
\list
\li If there is only one input file, the property \c input is available as syntactic sugar
for \c inputs[0].
\li The filenames of the output artifacts are available as \c outputs. If there is only one
of these, it can be referred to it as \c output.
\endlist
As a real-world example of a simplex rule, here is a simplified version
of \QBS' rule for transforming C++ sources into object files using gcc:
\code
import qbs.ModUtils
import qbs.Utilities
Rule {
id: compiler
inputs: ['cpp']
auxiliaryInputs: ['hpp']
Artifact {
fileTags: ['obj']
filePath: '.obj/' + Utilities.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var args = [];
if (product.moduleProperty('cpp', 'debugInformation'))
args.push('-g');
var warnings = product.moduleProperty('cpp', 'warningLevel')
if (warnings === 'none')
args.push('-w');
if (warnings === 'all') {
args.push('-Wall');
args.push('-Wextra');
}
if (product.moduleProperty('cpp', 'treatWarningsAsErrors'))
args.push('-Werror');
var includePaths = product.moduleProperty('cpp', 'includePaths');
for (i in includePaths)
args.push('-I' + includePaths[i]);
var defines = product.moduleProperty('cpp', 'defines');
for (i in defines)
args.push('-D' + defines[i]);
args.push('-c');
args.push(input.filePath);
args.push('-o');
args.push(output.filePath);
var compilerPath = ModUtils.moduleProperty(product, 'compilerPath');
var cmd = new Command(compilerPath, args);
cmd.description = 'compiling ' + input.fileName;
cmd.highlight = 'compiler';
return cmd;
}
}
\endcode
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 \c 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 item}{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 Rule Properties
\table
\header
\li Property
\li Type
\li Default
\li Description
\row
\li multiplex
\li bool
\li false
\li Determines whether this is a multiplex rule.
\row
\li inputs
\li string list
\li undefined
\li 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
inputs variable of the prepare script.
\row
\li auxiliaryInputs
\li string list
\li undefined
\li A list of file tags. This rule will be dependent on every other rule
that produces artifacts that are compatible with \a{auxiliaryInputs}.
Unlike \a{inputs}, the property \a{auxiliaryInputs} has no effect on the content of the
\a{inputs} variable in the \a{prepare} script.
\row
\li excludedAuxiliaryInputs
\li string list
\li undefined
\li A list of file tags. Connections to rules that produce these file tags are prevented.
This property has no effect on the content of the \a{inputs} variable in the \a{prepare}
script.
\row
\li inputsFromDependencies
\li string list
\li undefined
\li File tags 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 \a inputs variable of the prepare
script. Also, each output artifact of this rule will be dependent on
those artifacts.
\row
\li outputArtifacts
\li array of objects
\li undefined
\li An array of output artifacts, specified as JavaScript objects.
Example:
\code
outputArtifacts: [{filePath: "myfile.txt", fileTags: ["foo", "bar"]}]
\endcode
For a description of the possible properties, see the documentation of the
\l{Artifact item}.
Output artifacts can be specified either by \c{Rule.outputArtifacts} or by \c{Artifact}
items. Use \c{Rule.outputArtifacts} if the set of outputs is not fixed but dependent on
the input's content. If no file tags are provided, \QBS will apply all
\l{FileTagger Item}{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 \c{Rule.explicitlyDependsOn}.
\row
\li outputFileTags
\li string list
\li undefined
\li If output artifacts are specified by \c{Rule.outputArtifacts}, then
\c{Rule.outputFileTags} must be a list of file tags the rule potentially produces.
\row
\li condition
\li bool
\li true
\li If true, the rule is enabled, otherwise it does nothing.
\row
\li explicitlyDependsOn
\li string list
\li undefined
\li Each artifact that matches the file tags in \a explicitlyDependsOn
is added to the dependencies of each output node.
\row
\li prepare
\li script
\li undefined
\li 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)}.
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's exactly one output artifact.
\row
\li alwaysRun
\li bool
\li false
\li If true, the rule's commands are always executed, even if all output artifacts
are up to date.
\endtable
*/
|
