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
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
|
/****************************************************************************
**
** 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 index.html
\previouspage custom-modules.html
\nextpage reference.html
\page howtos.html
\title How-tos
This page provides concrete instructions for common scenarios.
\list
\li \l{How do I build a Qt-based project?}
\li \l{How do I make my app build against my library?}
\li \l{How do I use precompiled headers?}
\li \l{How do I make sure my generated sources are getting compiled?}
\li \l{How do I run my autotests?}
\li \l{How do I create a module for a third-party library?}
\li \l{How do I create application bundles and frameworks on iOS, macOS, tvOS, and watchOS?}
\li \l{How do I apply C/C++ preprocessor macros to only a subset of the files in my product?}
\li \l{How do I make the state of my Git repository available to my source files?}
\li \l{How do I limit the number of concurrent jobs for the linker only?}
\li \l{How do I add QML files to a project?}
\endlist
\section1 How do I build a Qt-based project?
First of all, your project files need to declare \l{Depends}{dependencies}
on \l{Qt} modules.
To build the project, you need a matching \e profile. The following commands
set up and use a Qt-specific profile:
\code
$ qbs setup-qt /usr/bin/qmake qt
$ cd my_project
$ qbs profile:qt
\endcode
If you plan to use this profile a lot, consider making it the default one:
\code
$ qbs config defaultProfile qt
$ cd my_project
$ qbs
\endcode
See \l{Managing Qt Versions} for more details.
\note These instructions are only relevant for building from the command line.
If you use Qt Creator, profiles are set up automatically from the information in the Kit.
\section1 How do I make my app build against my library?
This is achieved by introducing a \e dependency between the two products using the
\l{Depends} item. Here is a simple, but complete example:
\code
Project {
CppApplication {
name : "the-app"
files : [ "main.cpp" ]
Depends { name: "the-lib" }
}
DynamicLibrary {
name: "the-lib"
Depends { name: "cpp" }
files: [
"lib.cpp",
"lib.h",
]
Export {
Depends { name: "cpp" }
cpp.includePaths: [product.sourceDirectory]
}
}
}
\endcode
The product \c the-lib is a dynamic library. It expects other products to build against it, and
for that purpose, it exports an include path (via an \l{Export} item), so that the
source files in these products can include the library's header file.
The product \c the-app is an application that expresses its intent to link against \c the-lib
by declaring a dependency on it. Now \c main.cpp can include \c lib.h (because of the exported
include path) and the application binary will link against the library (because the linker
\l{Rule}{rule} in the \l{cpp} module considers library dependencies as inputs).
\note In a non-trivial project, the two products would not be defined in the same file.
Instead, you would put them into files of their own and use the
\l{Project::references}{Project.references} property to pull them into the project.
The product definitions would stay exactly the same. In particular, their location
in the project tree is irrelevant to the relationship between them.
\section1 How do I use precompiled headers?
If you use a \l Group item to add a precompiled header file to a product
and mark it with the \l{filetags-cpp}{relevant file tag} (\c c_pch_src,
\c cpp_pch_src, \c objc_pch_src, or \c objcpp_pch_src), it is used
automatically.
Only one precompiled header is allowed per product and language.
For example:
\code
CppApplication {
name: "the-app"
files: ["main.cpp"]
Group {
files: ["precompiled-header.pch"]
fileTags: ["cpp_pch_src"]
}
}
\endcode
\section1 How do I make sure my generated sources are getting compiled?
The rules in a \QBS project do not care whether its inputs are actual source files
listed on the right-hand side of a \l{Product::files}{files} property or artifacts
that were generated by another rule. For instance, the C++ compiler rule considers
all input files of type "cpp", no matter how they got into the product. The following
example project demonstrates this. One of its source files exists in the repository,
the other one is generated at build time. Both are getting compiled the same way.
\note Do not try to add the generated files to a \c files property. Declaring them
as rule outputs is all that is needed to make \QBS know about them.
\code
import qbs.TextFile
CppApplication {
files: ["impl.cpp", "impl.h"]
cpp.includePaths: sourceDirectory
Rule {
multiplex: true
Artifact { filePath: "main.cpp"; fileTags: "cpp" }
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating " + output.fileName;
cmd.sourceCode = function() {
var f = new TextFile(output.filePath, TextFile.WriteOnly);
f.writeLine("#include <impl.h>");
f.writeLine("int main()");
f.writeLine("{");
f.writeLine(" return functionFromImpl();");
f.writeLine("}");
f.close();
};
return cmd;
}
}
}
\endcode
\section1 How do I run my autotests?
There are two simple things you need to do in your project. Firstly, you
mark your test executables as such. This is done by adding the tag \c{"autotest"}
to the product type:
\code
CppApplication {
name: "test1"
type: base.concat("autotest")
// ...
}
\endcode
The second step is to instantiate an \l AutotestRunner product in your project:
\code
Project {
// ...
AutotestRunner { name: "run_my_tests" }
}
\endcode
Building an AutotestRunner product does not produce artifacts, but triggers execution of all
applications whose products are tagged as autotests:
\code
$ qbs -p run_my_tests
test1: PASS
test2: PASS
test3: FAIL
...
\endcode
See the \l{AutotestRunner}{AutotestRunner documentation} for how to fine-tune the behavior.
\section1 How do I create a module for a third-party library?
If you have pre-built binary files in your source tree, you can create
modules for them and then introduce dependencies between your project and
the modules to pull in the functionality of a third-party library.
Create the following folder structure to store the module files:
\code
$projectroot/modules/ThirdParty
\endcode
Then create a file in the directory that specifies the module properties
for each supported toolchain. The filename must have the \c .qbs extension.
The module will be pulled in if a product declares a dependency on it.
In the following example, \c lib1.dylib is a multi-architecture library
containing both 32-bit and 64-bit code.
\code
---ThirdParty.qbs---
Module {
Depends { name: "cpp" }
cpp.includePaths: ["/somewhere/include"]
Properties {
condition: qbs.targetOS.contains("android")
cpp.dynamicLibraries: ["/somewhere/android/" + Android.ndk.abi + "/lib1.so"]
}
Properties {
condition: qbs.targetOS.contains("macos")
cpp.dynamicLibraries: ["/somewhere/macos/lib1.dylib"]
}
Properties {
condition: qbs.targetOS.contains("windows") && qbs.architecture === "x86"
cpp.dynamicLibraries: ["/somewhere/windows_x86/lib1.lib"]
}
Properties {
condition: qbs.targetOS.contains("windows") && qbs.architecture === "x86_64"
cpp.dynamicLibraries: ["/somewhere/windows_x86_64/lib1.lib"]
}
}
\endcode
Finally, declare dependencies on \c ThirdParty in your project:
\code
CppApplication {
name: "the-app"
files: ["main.cpp"]
Depends { name: "ThirdParty" }
}
\endcode
\section1 How do I create application bundles and frameworks on iOS, macOS, tvOS, and watchOS?
Creating an application bundle or framework is achieved by introducing a
dependency on the \l{bundle} module and setting the \l{bundle::isBundle}
{bundle.isBundle} property to \c true.
Here is a simple example for an application:
\code
Application {
Depends { name: "cpp" }
Depends { name: "bundle" }
bundle.isBundle: true
name: "the-app"
files: ["main.cpp"]
}
\endcode
and for a framework:
\code
DynamicLibrary {
Depends { name: "cpp" }
Depends { name: "bundle" }
bundle.isBundle: true
name: "the-lib"
files: ["lib.cpp", "lib.h"]
}
\endcode
\QBS also supports building static frameworks. You can create one by
replacing the \l{DynamicLibrary} item with a \l{StaticLibrary} item in the
example above.
\note When using the \l{Application} item (or convenience items, such as
\l{CppApplication}, \l{DynamicLibrary}, and \l{StaticLibrary}), your
products will be built as bundles on Apple platforms by default (this
behavior is subject to change in a future release).
To explicitly control whether your product is built as a bundle, set the \c bundle.isBundle
property. Setting the \l{Product::}{consoleApplication} property of your
product will also influence whether your product is built as a bundle.
Building your application against your framework is the same as linking a normal dynamic or
static library; see the \l{How do I make my app build against my library?} section for an
example.
\section1 How do I apply C/C++ preprocessor macros to only a subset of the files in my product?
Use a \l{Group} item to define a subset of project files. To add
macros within the group, you need to use the \c outer.concat property,
because you are adding macros to those specified in the outer scope.
In the following example, \c MACRO_EVERYWHERE is defined for all files in
the \l{Product} unless a Group overrides the macro, whereas
\c MACRO_GROUP is only defined for \c groupFile.cpp.
\code
Product {
Depends { name: "cpp" }
cpp.defines: ["MACRO_EVERYWHERE"]
Group {
cpp.defines: outer.concat("MACRO_GROUP")
files: "groupFile.cpp"
}
}
\endcode
The \c cpp.defines statements inside a \c Group only apply to the files in
that \c Group, and therefore you cannot use a \c Group to include a bunch of
files and globally visible macros. The macros must be specified in a
\l{Properties} item at the same level as the \c Group if
they need to be visible to files outside the \c Group:
\code
Product {
Depends { name: "cpp" }
Group {
condition: project.supportMyFeature
files: "myFile.cpp"
}
property stringList commonDefines: ["ONE", "TWO"]
Properties {
condition: project.supportMyFeature
cpp.defines: commonDefines.concat("MYFEATURE_SUPPORTED")
}
}
\endcode
\section1 How do I make the state of my Git repository available to my source files?
Add a dependency to the \l{vcs} module to your product:
\code
CppApplication {
// ...
Depends { name: "vcs" }
// ...
}
\endcode
Your source files will now have access to a macro whose value is a string representing the
current Git or Subversion HEAD:
\code
#include <vcs-repo-state.h>
#include <iostream>
int main()
{
std::cout << "I was built from " << VCS_REPO_STATE << std::endl;
}
\endcode
This value is also available via the \l{vcs::repoState}{vcs.repoState}
property.
\section1 How do I limit the number of concurrent jobs for the linker only?
\target job-pool-howto
While it is usually desirable to run as many compiler jobs as there are CPU cores,
the same is not true for linker jobs. The reason is that linkers are typically
I/O bound rather than CPU bound. When building large libraries, they also tend
to use up enormous amounts of memory. Therefore, we'd like to make sure that
only a few linkers are running at the same time without limiting other types
of jobs. In \QBS, this is achieved via \e{job pools}. There are several ways
to make use of them.
Firstly, you can provide a limit via the command line:
\code
$ qbs --job-limits linker:4
\endcode
The above call instructs \QBS to run at most four linker instances at the same
time, while leaving the general number of concurrent jobs at the default
value, which is derived from the number of CPU cores.
The \c linker string on the command line refers to the job pool of the same
name, which the \l{cpp-job-pools}{cpp module} assigns to all its commands that
invoke a linker.
Secondly, you can set a limit via the settings, either generally
or for a specific profile:
\code
$ qbs config preferences.jobLimit.linker 4
$ qbs config profiles.myprofile.preferences.jobLimit.linker 2
\endcode
And finally, you can also set the limit per project or per product, using a
\l JobLimit item:
\code
Product {
name: "my_huge_library"
JobLimit {
jobPool: "linker"
jobCount: 1
}
// ...
}
\endcode
The above construct ensures that this specific library is never linked at
the same time as any other binary in the project.
Job limits set on the command line override those from the settings, which in turn
override the ones defined within a project. Use the \c{--enforce-project-job-limits}
option to give the job limits defined via \c JobLimit items maximum precedence.
\section1 How do I add QML files to a project?
The simplest way to add QML files to a project is to add them to a
\l {The Qt Resource System}{resource file}:
\code
QtGuiApplication {
// ...
files: "main.cpp"
Group {
prefix: "qml/"
files: ["main.qml", "HomePage.qml"]
fileTags: ["qt.qml.qml", "qt.core.resource_data"]
}
}
\endcode
In the example above, we declare each QML file as having the
\l {filetags-qtcore}{"qt.core.resource_data"} file tag. This ensures
that it is added to a generated resource file.
*/
|