Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qbs Quick Reference: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=Introduction=
[[Category:Tools::qbs]]


Qbs is the next-generation build system [https://blog.qt.io/blog/2012/02/15/introducing-qbs/ initially introduced in the Qt Labs Blog] ''[blog.qt.io]''. This page is intended as a quick guide to porting project files from qmake *.pro syntax to *.qbs. It is not intended to supplant the official documentation, rather to be a quick summary of the current status of qbs functionality with a focus on how to port from qmake.
[toc align_right="yes" depth="2"]


Some things at the time of writing have no equivalent qbs syntax. Bugtracker links are included for missing functionality, where known. And finally this is based on my incomplete current understanding of qbs, so there may be errors or indeed things which have changed by the time you read this <span class="smiley">:)</span>
= Introduction =


=Qbs Manual=
Qbs is the next-generation build system &quot;initially introduced in the Qt Labs Blog&amp;quot;:https://blog.qt.io/blog/2012/02/15/introducing-qbs/. This page is intended as a quick guide to porting project files from qmake '''.pro syntax to'''.qbs. It is not intended to supplant the official documentation, rather to be a quick summary of the current status of qbs functionality with a focus on how to port from qmake.
 
Some things at the time of writing have no equivalent qbs syntax. Bugtracker links are included for missing functionality, where known. And finally this is based on my incomplete current understanding of qbs, so there may be errors or indeed things which have changed by the time you read this :)
 
= Qbs Manual =


The full Qbs Manual is found at http://doc.qt.io/qbs
The full Qbs Manual is found at http://doc.qt.io/qbs


=qbs equivalents=
= qbs equivalents =


==<span class="caps">TEMPLATE</span> = app==
== TEMPLATE = app ==


Use Application or CppApplication as the product:
Use Application or CppApplication as the product:
<code>CppApplication {<br /> name: &quot;helloworld&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> …<br />}<br /></code>


This is roughly equivalent to:
This is roughly equivalent to:


except that in the first example, the type is “applicationbundle” on <span class="caps">OSX</span>.
<code>Product {<br /> name: &quot;helloworld&amp;quot;<br /> type: &quot;application&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> Depends { name: &quot;cpp&amp;quot; }<br /> …<br />}<br /></code>


==<span class="caps">TEMPLATE</span> = lib==
except that in the first example, the type is &quot;applicationbundle&amp;quot; on OSX.
 
== TEMPLATE = lib ==


Use DynamicLibrary as the product:
Use DynamicLibrary as the product:


==<span class="caps">TARGET</span> = myappname==
<code><br />DynamicLibrary {<br /> name: &quot;mydll&amp;quot;<br /> files: [&quot;stuff.cpp&amp;quot;]<br /> Depends { name: &quot;cpp&amp;quot; }<br /> …<br />}<br /></code>
 
== TARGET = myappname ==


Use the “name” property, see the <span class="caps">TEMPLATE</span> example above.
Use the &quot;name&amp;quot; property, see the TEMPLATE example above.


==<span class="caps">HEADERS</span>, <span class="caps">SOURCES</span>, <span class="caps">FORMS</span>, <span class="caps">RESOURCES</span>==
== HEADERS, SOURCES, FORMS, RESOURCES ==


Include in files section, eg
Include in files section, eg
<code>files: ['thing.h', 'thing.cpp', 'thing.ui', 'myapp.qrc']<br /></code>


qbs will use file taggers to figure out what kind of file it is dealing with.
qbs will use file taggers to figure out what kind of file it is dealing with.


==<span class="caps">CONFIG</span> += console==
== CONFIG ''= console
<br /><code>Application {<br /> name: &quot;helloworld&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> consoleApplication: true<br /> …<br />}<br /></code>
<br />h2. CONFIG''= designer_defines ==


==<span class="caps">CONFIG</span> += designer_defines==
<code>DynamicLibrary {<br /> name: &quot;myplugin&amp;quot;<br /> files: [&quot;foo.cpp&amp;quot;, …]<br /> Depends { name: &quot;cpp&amp;quot; }<br /> cpp.defines: [&quot;QDESIGNER_EXPORT_WIDGETS&amp;quot;]<br /> …<br />}<br /></code>


==QT += modulename==
== QT ''= modulename
<br />Add an appropriate Depends section to the product. For example:
<br /><code>Product {<br /> Depends { name: &quot;Qt.core&amp;quot; }<br /> // …or…<br /> Depends { name: &quot;Qt&amp;quot;; submodules: [&quot;core&amp;quot;, &quot;gui&amp;quot;, &quot;network&amp;quot;] }<br />}<br /></code>
<br />Both forms are equivalent, the first form being quicker to type if you depend on just one module and the second more flexible if you have more complex dependencies.
<br />h2. DEFINES''= MACRO ==


Add an appropriate Depends section to the product. For example:
Use the following: Note that in order to reference cpp.defines you must specify a dependency on the cpp module.<br /><code>Depends { name: 'cpp' }<br />…<br />cpp.defines: ['SUPPORT_COOL_STUFF']<br /></code>


Both forms are equivalent, the first form being quicker to type if you depend on just one module and the second more flexible if you have more complex dependencies.
The cpp module might define default preprocessor macros. For example on Windows UNICODE is predefined.<br />These are stored in the property cpp.platformDefines.<br />To override these macros do:<br /><code>Product {<br /> Depends { name: 'cpp' }<br /> …<br /> cpp.platformDefines: ['MY_SPECIAL_DEFINE', 'UNICODE']<br /></code>
 
==<span class="caps">DEFINES</span> += <span class="caps">MACRO</span>==
 
Use the following: Note that in order to reference cpp.defines you must specify a dependency on the cpp module.<br />
 
The cpp module might define default preprocessor macros. For example on Windows <span class="caps">UNICODE</span> is predefined.<br /> These are stored in the property cpp.platformDefines.<br /> To override these macros do:<br />


To add macros within a group, you need to use outer.concat rather than base.concat(), because you are adding additional macros to what is specified in the outer scope:
To add macros within a group, you need to use outer.concat rather than base.concat(), because you are adding additional macros to what is specified in the outer scope:


cpp.defines statements inside a group only apply to the files in that group – therefore you cannot use a group to include a bunch of files and globally-visible macros – the macros must go in a Properties block at the same level as the group if they need to be visible to files outside the group:
<code>Product {<br /> Depends { name: 'cpp' }<br /> …<br /> cpp.defines: ['MACRO_EVERYWHERE'] // This is defined for all files in this product (unless a group overrides it!)<br /> Group {<br /> cpp.defines: outer.concat('MACRO_GROUP')<br /> files: groupFile.cpp<br /> // MACRO_GROUP is only defined in groupFile.cpp<br /> // MACRO_EVERYWHERE is also defined in groupFile.cpp because of the outer.concat<br /> }<br />}<br /></code>


==<span class="caps">INCLUDEPATH</span> += dir==
cpp.defines statements inside a group only apply to the files in that group - therefore you cannot use a group to include a bunch of files and globally-visible macros - the macros must go in a Properties block at the same level as the group if they need to be visible to files outside the group:


==<span class="caps">CONFIG</span> -= Qt==
<code>Product {<br /> Depends { name: 'cpp' }<br /> …<br /> Group {<br /> condition: supportFoobar === true<br /> files: fooFile.cpp<br /> }


Just don’t declare Qt as a dependency. Probably you’d want:
property stringList commonDefines: [&quot;ONE&amp;quot;, &quot;TWO&amp;quot;]<br /> Properties {<br /> condition: supportFoobar === true<br /> cpp.defines: commonDefines.concat(&quot;FOOBAR_SUPPORTED&amp;quot;)<br /> }<br /> Properties {<br /> cpp.defines: commonDefines // else case for the Properties chain<br /> }<br />}<br /></code>


==RC_FILE==
== INCLUDEPATH ''= dir
<br /><code>cpp.includePaths: [ '..', 'some/other/dir']<code>
<br />h2. CONFIG <s>= Qt
<br />Just don't declare Qt as a dependency. Probably you'd want:
<br /></code>Depends { name: &quot;cpp&amp;quot; }</code>
<br />h2. RC_FILE
<br />Just add the file to the &quot;files&amp;quot; list.
<br />h2. QMAKE_INFO_PLIST
<br />Set the cpp.infoPlistFile property.
<br />h2. ICON,
<br />Not yet implemented. See &quot;QBS-73&amp;quot;:https://bugreports.qt.io/browse/QBS-73.
<br />h2. TEMPLATE = subdirs
<br />Inside a &quot;Project&amp;quot; item, use &quot;references&amp;quot;:
<br /><code>Project {<br /> references: [<br /> &quot;app/app.qbs&amp;quot;,<br /> &quot;lib/lib.qbs&amp;quot;<br /> ]<br />}<br /></code>
<br />h2. DESTDIR
<br />Use the destinationDirectory property:
<br /><code><br />DynamicLibrary {<br /> name: &quot;mydll&amp;quot;<br /> destinationDirectory: &quot;libDir&amp;quot;<br /> …<br />}<br /></code>
<br />h2. message(), warning(), error()
<br />You can use the JavaScript function print for printing messages and throw exceptions on the right hand side of property bindings.
<br /><code>Product {<br /> name: {<br /> print(&quot;—</s>&amp;gt; now evaluating the product name&amp;quot;);<br /> return &quot;theName&amp;quot;;<br /> }<br /> Depends {name: &quot;cpp&amp;quot;}<br /> cpp.includePath: {<br /> throw &quot;I don't know. Something bad happened.&quot;<br /> return [];<br /> }<br />}</code>


Just add the file to the “files” list.
<br />h2. Others not mentioned above
<br />Either I've missed them, or they're not yet implemented.
<br />h1. .pro and .pri
<br />The top-level .qbs file contains the &quot;Project&amp;quot; definition. A project can contain multiple products, so you may find that multiple .pro files can be expressed in a single .qbs. The subdirs pattern will typically convert to a single .qbs containing references to multiple .qbs files. Each .qbs file would then define a single product or sub-project.
<br />.qbs files can also be used like .pri files in that a top-level .qbs can include sections defined in another .qbs. For example:
<br /><code><br /> —CrazyProduct.qbs—<br /> import qbs.base 1.0
<br /> Product {<br /> property string craziness: &quot;low&amp;quot;<br /> }
<br /> —hellocrazyworld.qbs—<br /> CrazyProduct {<br /> craziness: &quot;enormous&amp;quot;<br /> name: &quot;hellocrazyworld&amp;quot;<br /> // …<br /> }<br /></code>
<br />.qbs files in the same directory as the top-level .qbs file are picked up automatically. Others must be explicitly imported and named using an &quot;import … as …&quot; statement:
<br /><code><br />import qbs.base 1.0<br />import &quot;../CrazyProduct.qbs&amp;quot; as CrazyProduct<br />CrazyProduct {<br /> craziness: &quot;enormous&amp;quot;<br /> name: &quot;hellocrazyworld&amp;quot;<br /> // …<br />}<br /></code>
<br />h1. Conditionals
<br />Instead of the qmake syntax of &quot;windows { … }&quot; or &quot;macx:…&quot;, you specify a &quot;condition&amp;quot; property in the relevant block. Conditionally-compiled files should be collected in a &quot;Group&amp;quot; block, while platform-specific properties should go in a &quot;Properties&amp;quot; block rather than being put in the main (outer) block:
<br /><code><br />Group {<br /> condition: qbs.targetOS == &quot;windows&amp;quot;<br /> files: [<br /> &quot;harddiskdeleter_win.cpp&amp;quot;,<br /> &quot;blowupmonitor_win.cpp&amp;quot;,<br /> &quot;setkeyboardonfire_win.cpp&amp;quot;<br /> ]<br />}
<br />Properties {<br /> condition: qbs.targetOS == &quot;linux&amp;quot;<br /> cpp.defines: outer.concat([ &quot;USE_BUILTIN_DESTRUCTORS&amp;quot;])<br />}<br /></code>
<br />See the DEFINES section above for important information about how conditionals and cpp.defines interact.
<br />h1. C''+ compiler options ==


==<span class="caps">QMAKE</span>_INFO_PLIST==
Here is a selection of options that are supported. The full list can be found in share/qbs/modules/cpp/CppModule.qbs in the qbs source tree, these are some of the more useful:
 
Set the cpp.infoPlistFile property.
 
==<span class="caps">ICON</span>,==
 
Not yet implemented. See [https://bugreports.qt.io/browse/QBS-73 <span class="caps">QBS</span>-73] ''[bugreports.qt.io]''.
 
==<span class="caps">TEMPLATE</span> = subdirs==
 
Inside a “Project” item, use “references”:
 
==<span class="caps">DESTDIR</span>==
 
Use the destinationDirectory property:
 
==message(), warning(), error()==
 
You can use the JavaScript function print for printing messages and throw exceptions on the right hand side of property bindings.
 
==Others not mentioned above==
 
Either I’ve missed them, or they’re not yet implemented.
 
=.pro and .pri=
 
The top-level .qbs file contains the “Project” definition. A project can contain multiple products, so you may find that multiple .pro files can be expressed in a single .qbs. The subdirs pattern will typically convert to a single .qbs containing references to multiple .qbs files. Each .qbs file would then define a single product or sub-project.
 
.qbs files can also be used like .pri files in that a top-level .qbs can include sections defined in another .qbs. For example:
 
.qbs files in the same directory as the top-level .qbs file are picked up automatically. Others must be explicitly imported and named using an “import … as …” statement:


=Conditionals=
<code><br />cpp.optimization: &quot;none&amp;quot; // or &quot;fast&amp;quot;<br />cpp.debugInformation: true<br />cpp.staticLibraries: &quot;libraryName&amp;quot;<br />cpp.dynamicLibraries: &quot;libraryName&amp;quot;<br />cpp.frameworks: &quot;osxFrameworkName&amp;quot;<br />cpp.precompiledHeader: &quot;myheader.pch&amp;quot;<br />cpp.warningLevel: &quot;all&amp;quot; // or &quot;none&amp;quot;, &quot;default&amp;quot;<br />cpp.treatWarningsAsErrors: true<br /></code>


Instead of the qmake syntax of “windows { … }” or “macx:…”, you specify a “condition” property in the relevant block. Conditionally-compiled files should be collected in a “Group” block, while platform-specific properties should go in a “Properties” block rather than being put in the main (outer) block:
Note that setting things like cflags directly is discouraged (because they are compiler-dependent), and higher-level alternatives like cpp.optimization: &quot;fast&amp;quot; should be used if available.


See the <span class="caps">DEFINES</span> section above for important information about how conditionals and cpp.defines interact.
= Installing files =
 
=C++ compiler options=
 
Here is a selection of options that are supported. The full list can be found in share/qbs/modules/cpp/CppModule.qbs in the qbs source tree, these are some of the more useful:
 
Note that setting things like cflags directly is discouraged (because they are compiler-dependent), and higher-level alternatives like cpp.optimization: “fast” should be used if available.
 
=Installing files=


Create a group containing the files, and set qbs.install and qbs.installDir:
Create a group containing the files, and set qbs.install and qbs.installDir:


For files generated by the build (e.g. an executable), you need to match them by their file tag:<br />
<code><br />Group {<br /> qbs.install: true<br /> qbs.installDir: &quot;lib/myproj/&amp;quot;<br /> files: [<br /> &quot;Menu.qml&amp;quot;,<br /> &quot;SomeImportantFile.bin&amp;quot;<br /> ]<br />}<br /></code>


The installation happens by invoking the “qbs install” command:<br />
For files generated by the build (e.g. an executable), you need to match them by their file tag:<br /><code><br />Group {<br /> qbs.install: true<br /> qbs.installDir: &quot;bin&amp;quot;<br /> fileTagsFilter: &quot;application&amp;quot;<br />}<br /></code>


=Command-line examples=
The installation happens by invoking the &quot;qbs install&amp;quot; command:<br /><code><br />$ qbs install —install-root /tmp/myProject<br /></code>


64-bit:<br />
= Command-line examples =


=“Magic” variables=
64-bit:<br /><code>qbs <s>f /path/to/project.qbs —products productname qbs.architecture:x86_64<br /></code>
<br />h1. &quot;Magic&amp;quot; variables
<br />Variables defined in various scopes, which may not be obvious:
<br />h2. qbs
<br />This has lots of useful things in, such as: targetOS (&quot;windows&amp;quot;, &quot;linux&amp;quot;, &quot;macx&amp;quot;, …); buildVariant (&quot;debug&amp;quot;, &quot;release&amp;quot;); architecture (&quot;x86&amp;quot;, &quot;x86_64&amp;quot;, …)
<br />h2. project
<br />Valid anywhere in your project, needed to refer to project properties from within a product:
<br /><code>Project {<br /> property string version: &quot;1.0&amp;quot;
<br /> Product {<br /> cpp.defines: [&quot;PROJECT_VERSION=&quot; + project.version]<br /> }<br />}<br /></code>
<br />h2. buildDirectory
<br />The top-level build directory. By default will be a subdirectory in the directory where you invoked qbs from, whose name is derived from the current profile.
<br />h2. Module names
<br />Modules that are declared as dependencies can be referred to by their name and their properties accessed</s> for example:


Variables defined in various scopes, which may not be obvious:
<code>Product {<br /> Depends { name: &quot;Qt.quick&amp;quot; }<br /> Qt.quick.qmlDebugging: false<br />}<br /></code>


==qbs==
== Inside custom javascript ==


This has lots of useful things in, such as: targetOS (“windows”, “linux”, “macx”, …); buildVariant (“debug”, “release”); architecture (“x86”, “x86_64”, …)
Generally when writing custom JavaScript logic, things are referenced through the top-level &quot;product&amp;quot; variable. In particular, to get the product's value of the property &quot;baz&amp;quot; of a module &quot;foo&amp;quot;, use product.moduleProperty(&quot;foo&amp;quot;, &quot;baz&amp;quot;). For list values that get automatically combined, like includePaths, use product.moduleProperties(&quot;foo&amp;quot;, &quot;baz&amp;quot;).


==project==
<code>Group {<br /> condition: qbs.targetOS === &quot;windows&amp;quot;<br /> files: [ &quot;hcf.cpp&amp;quot; ]<br />}<br /></code>
 
Valid anywhere in your project, needed to refer to project properties from within a product:
 
==buildDirectory==
 
The top-level build directory. By default will be a subdirectory in the directory where you invoked qbs from, whose name is derived from the current profile.
 
==Module names==
 
Modules that are declared as dependencies can be referred to by their name and their properties accessed – for example:
 
==Inside custom javascript==
 
Generally when writing custom JavaScript logic, things are referenced through the top-level “product” variable. In particular, to get the product’s value of the property “baz” of a module “foo”, use product.moduleProperty(“foo”, “baz”). For list values that get automatically combined, like includePaths, use product.moduleProperties(“foo”, “baz”).


and
and


===Categories:===
<code>Group {<br /> files: {<br /> if (product.moduleProperty(&quot;qbs&amp;quot;, &quot;targetOS&amp;quot;) === &quot;windows&amp;quot;) {<br /> return [ &quot;hcf.cpp&amp;quot; ];<br /> } else {<br /> return [];<br /> }<br /> }<br />}
 
* [[:Category:Tools|Tools]]
** [[:Category:Tools::qbs|qbs]]

Revision as of 14:22, 23 February 2015


[toc align_right="yes&quot; depth="2&quot;]

Introduction

Qbs is the next-generation build system "initially introduced in the Qt Labs Blog&quot;:https://blog.qt.io/blog/2012/02/15/introducing-qbs/. This page is intended as a quick guide to porting project files from qmake .pro syntax to.qbs. It is not intended to supplant the official documentation, rather to be a quick summary of the current status of qbs functionality with a focus on how to port from qmake.

Some things at the time of writing have no equivalent qbs syntax. Bugtracker links are included for missing functionality, where known. And finally this is based on my incomplete current understanding of qbs, so there may be errors or indeed things which have changed by the time you read this :)

Qbs Manual

The full Qbs Manual is found at http://doc.qt.io/qbs

qbs equivalents

TEMPLATE = app

Use Application or CppApplication as the product:

CppApplication {<br /> name: &quot;helloworld&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> <br />}<br />

This is roughly equivalent to:

Product {<br /> name: &quot;helloworld&amp;quot;<br /> type: &quot;application&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> Depends { name: &quot;cpp&amp;quot; }<br /> <br />}<br />

except that in the first example, the type is "applicationbundle&quot; on OSX.

TEMPLATE = lib

Use DynamicLibrary as the product:

<br />DynamicLibrary {<br /> name: &quot;mydll&amp;quot;<br /> files: [&quot;stuff.cpp&amp;quot;]<br /> Depends { name: &quot;cpp&amp;quot; }<br /> <br />}<br />

TARGET = myappname

Use the "name&quot; property, see the TEMPLATE example above.

HEADERS, SOURCES, FORMS, RESOURCES

Include in files section, eg

files: ['thing.h', 'thing.cpp', 'thing.ui', 'myapp.qrc']<br />

qbs will use file taggers to figure out what kind of file it is dealing with.

== CONFIG = console


Application {<br /> name: &quot;helloworld&amp;quot;<br /> files: &quot;main.cpp&amp;quot;<br /> consoleApplication: true<br /> <br />}<br />


h2. CONFIG= designer_defines ==

DynamicLibrary {<br /> name: &quot;myplugin&amp;quot;<br /> files: [&quot;foo.cpp&amp;quot;, ]<br /> Depends { name: &quot;cpp&amp;quot; }<br /> cpp.defines: [&quot;QDESIGNER_EXPORT_WIDGETS&amp;quot;]<br /> <br />}<br />

== QT = modulename
Add an appropriate Depends section to the product. For example:


Product {<br /> Depends { name: &quot;Qt.core&amp;quot; }<br /> // …or…<br /> Depends { name: &quot;Qt&amp;quot;; submodules: [&quot;core&amp;quot;, &quot;gui&amp;quot;, &quot;network&amp;quot;] }<br />}<br />


Both forms are equivalent, the first form being quicker to type if you depend on just one module and the second more flexible if you have more complex dependencies.
h2. DEFINES= MACRO ==

Use the following: Note that in order to reference cpp.defines you must specify a dependency on the cpp module.

Depends { name: 'cpp' }<br /><br />cpp.defines: ['SUPPORT_COOL_STUFF']<br />

The cpp module might define default preprocessor macros. For example on Windows UNICODE is predefined.
These are stored in the property cpp.platformDefines.
To override these macros do:

Product {<br /> Depends { name: 'cpp' }<br /> <br /> cpp.platformDefines: ['MY_SPECIAL_DEFINE', 'UNICODE']<br />

To add macros within a group, you need to use outer.concat rather than base.concat(), because you are adding additional macros to what is specified in the outer scope:

Product {<br /> Depends { name: 'cpp' }<br /> <br /> cpp.defines: ['MACRO_EVERYWHERE'] // This is defined for all files in this product (unless a group overrides it!)<br /> Group {<br /> cpp.defines: outer.concat('MACRO_GROUP')<br /> files: groupFile.cpp<br /> // MACRO_GROUP is only defined in groupFile.cpp<br /> // MACRO_EVERYWHERE is also defined in groupFile.cpp because of the outer.concat<br /> }<br />}<br />

cpp.defines statements inside a group only apply to the files in that group - therefore you cannot use a group to include a bunch of files and globally-visible macros - the macros must go in a Properties block at the same level as the group if they need to be visible to files outside the group:

Product {<br /> Depends { name: 'cpp' }<br /> <br /> Group {<br /> condition: supportFoobar === true<br /> files: fooFile.cpp<br /> }

property stringList commonDefines: [&quot;ONE&amp;quot;, &quot;TWO&amp;quot;]<br /> Properties {<br /> condition: supportFoobar === true<br /> cpp.defines: commonDefines.concat(&quot;FOOBAR_SUPPORTED&amp;quot;)<br /> }<br /> Properties {<br /> cpp.defines: commonDefines // else case for the Properties chain<br /> }<br />}<br />

== INCLUDEPATH = dir


cpp.includePaths: [ '..', 'some/other/dir']<code>
<br />h2. CONFIG <s>= Qt
<br />Just don't declare Qt as a dependency. Probably you'd want:
<br />

Depends { name: "cpp&quot; }


h2. RC_FILE
Just add the file to the "files&quot; list.
h2. QMAKE_INFO_PLIST
Set the cpp.infoPlistFile property.
h2. ICON,
Not yet implemented. See "QBS-73&quot;:https://bugreports.qt.io/browse/QBS-73.
h2. TEMPLATE = subdirs
Inside a "Project&quot; item, use "references&quot;:


Project {<br /> references: [<br /> &quot;app/app.qbs&amp;quot;,<br /> &quot;lib/lib.qbs&amp;quot;<br /> ]<br />}<br />


h2. DESTDIR
Use the destinationDirectory property:


<br />DynamicLibrary {<br /> name: &quot;mydll&amp;quot;<br /> destinationDirectory: &quot;libDir&amp;quot;<br /> <br />}<br />


h2. message(), warning(), error()
You can use the JavaScript function print for printing messages and throw exceptions on the right hand side of property bindings.


Product {<br /> name: {<br /> print(&quot;</s>&amp;gt; now evaluating the product name&amp;quot;);<br /> return &quot;theName&amp;quot;;<br /> }<br /> Depends {name: &quot;cpp&amp;quot;}<br /> cpp.includePath: {<br /> throw &quot;I don't know. Something bad happened.&quot;<br /> return [];<br /> }<br />}


h2. Others not mentioned above
Either I've missed them, or they're not yet implemented.
h1. .pro and .pri
The top-level .qbs file contains the "Project&quot; definition. A project can contain multiple products, so you may find that multiple .pro files can be expressed in a single .qbs. The subdirs pattern will typically convert to a single .qbs containing references to multiple .qbs files. Each .qbs file would then define a single product or sub-project.
.qbs files can also be used like .pri files in that a top-level .qbs can include sections defined in another .qbs. For example:


<br /> CrazyProduct.qbs<br /> import qbs.base 1.0
<br /> Product {<br /> property string craziness: &quot;low&amp;quot;<br /> }
<br /> hellocrazyworld.qbs<br /> CrazyProduct {<br /> craziness: &quot;enormous&amp;quot;<br /> name: &quot;hellocrazyworld&amp;quot;<br /> // …<br /> }<br />


.qbs files in the same directory as the top-level .qbs file are picked up automatically. Others must be explicitly imported and named using an "import … as …" statement:


<br />import qbs.base 1.0<br />import &quot;../CrazyProduct.qbs&amp;quot; as CrazyProduct<br />CrazyProduct {<br /> craziness: &quot;enormous&amp;quot;<br /> name: &quot;hellocrazyworld&amp;quot;<br /> // …<br />}<br />


h1. Conditionals
Instead of the qmake syntax of "windows { … }" or "macx:…", you specify a "condition&quot; property in the relevant block. Conditionally-compiled files should be collected in a "Group&quot; block, while platform-specific properties should go in a "Properties&quot; block rather than being put in the main (outer) block:


<br />Group {<br /> condition: qbs.targetOS == &quot;windows&amp;quot;<br /> files: [<br /> &quot;harddiskdeleter_win.cpp&amp;quot;,<br /> &quot;blowupmonitor_win.cpp&amp;quot;,<br /> &quot;setkeyboardonfire_win.cpp&amp;quot;<br /> ]<br />}
<br />Properties {<br /> condition: qbs.targetOS == &quot;linux&amp;quot;<br /> cpp.defines: outer.concat([ &quot;USE_BUILTIN_DESTRUCTORS&amp;quot;])<br />}<br />


See the DEFINES section above for important information about how conditionals and cpp.defines interact.
h1. C+ compiler options ==

Here is a selection of options that are supported. The full list can be found in share/qbs/modules/cpp/CppModule.qbs in the qbs source tree, these are some of the more useful:

<br />cpp.optimization: &quot;none&amp;quot; // or &quot;fast&amp;quot;<br />cpp.debugInformation: true<br />cpp.staticLibraries: &quot;libraryName&amp;quot;<br />cpp.dynamicLibraries: &quot;libraryName&amp;quot;<br />cpp.frameworks: &quot;osxFrameworkName&amp;quot;<br />cpp.precompiledHeader: &quot;myheader.pch&amp;quot;<br />cpp.warningLevel: &quot;all&amp;quot; // or &quot;none&amp;quot;, &quot;default&amp;quot;<br />cpp.treatWarningsAsErrors: true<br />

Note that setting things like cflags directly is discouraged (because they are compiler-dependent), and higher-level alternatives like cpp.optimization: "fast&quot; should be used if available.

Installing files

Create a group containing the files, and set qbs.install and qbs.installDir:

<br />Group {<br /> qbs.install: true<br /> qbs.installDir: &quot;lib/myproj/&amp;quot;<br /> files: [<br /> &quot;Menu.qml&amp;quot;,<br /> &quot;SomeImportantFile.bin&amp;quot;<br /> ]<br />}<br />

For files generated by the build (e.g. an executable), you need to match them by their file tag:

<br />Group {<br /> qbs.install: true<br /> qbs.installDir: &quot;bin&amp;quot;<br /> fileTagsFilter: &quot;application&amp;quot;<br />}<br />

The installation happens by invoking the "qbs install&quot; command:

<br />$ qbs install install-root /tmp/myProject<br />

Command-line examples

64-bit:

qbs <s>f /path/to/project.qbs products productname qbs.architecture:x86_64<br />


h1. "Magic&quot; variables
Variables defined in various scopes, which may not be obvious:
h2. qbs
This has lots of useful things in, such as: targetOS ("windows&quot;, "linux&quot;, "macx&quot;, …); buildVariant ("debug&quot;, "release&quot;); architecture ("x86&quot;, "x86_64&quot;, …)
h2. project
Valid anywhere in your project, needed to refer to project properties from within a product:


Project {<br /> property string version: &quot;1.0&amp;quot;
<br /> Product {<br /> cpp.defines: [&quot;PROJECT_VERSION=&quot; + project.version]<br /> }<br />}<br />


h2. buildDirectory
The top-level build directory. By default will be a subdirectory in the directory where you invoked qbs from, whose name is derived from the current profile.
h2. Module names
Modules that are declared as dependencies can be referred to by their name and their properties accessed for example:

Product {<br /> Depends { name: &quot;Qt.quick&amp;quot; }<br /> Qt.quick.qmlDebugging: false<br />}<br />

Inside custom javascript

Generally when writing custom JavaScript logic, things are referenced through the top-level "product&quot; variable. In particular, to get the product's value of the property "baz&quot; of a module "foo&quot;, use product.moduleProperty("foo&quot;, "baz&quot;). For list values that get automatically combined, like includePaths, use product.moduleProperties("foo&quot;, "baz&quot;).

Group {<br /> condition: qbs.targetOS === &quot;windows&amp;quot;<br /> files: [ &quot;hcf.cpp&amp;quot; ]<br />}<br />

and

Group {
files: {
if (product.moduleProperty("qbs&quot;, "targetOS&quot;) === "windows&quot;) {
return [ "hcf.cpp&quot; ];
} else {
return [];
}
}
}