path: root/doc
diff options
authorChristian Kandeler <christian.kandeler@qt.io>2019-01-18 16:02:43 +0100
committerChristian Kandeler <christian.kandeler@qt.io>2019-02-12 09:12:39 +0000
commitc4e60ed8283aa7a86e13c09113e7fec6bf41cc42 (patch)
tree6cefbf3ece17e255c3962e69573abc88bef060ef /doc
parent17058d1fc537e40e7dda9d6e48ccfb24ea1220f7 (diff)
Detect Qt via a module provider
Creation of qbs modules for Qt is now done on demand during project resolving. The qmake executable(s) are looked up via PATH or taken from the Qt.qmakeFilePaths provider property. As a result, Qt projects can now be built without a profile. The qtprofilesetup library is gone; its code is now in the module provider. I kept the C++ -> JavaScript conversion as straightforward as possible and mostly resisted the temptation to "optimize". The setup-qt tool still exists and mainly sets Qt.qmakeFilePaths. [ChangeLog] It is no longer required to call setup-qt before building Qt projects. Change-Id: I5b7e4711ec47b996911c499f29d8129d90e4731e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Diffstat (limited to 'doc')
2 files changed, 21 insertions, 5 deletions
diff --git a/doc/qbs.qdoc b/doc/qbs.qdoc
index f559b481d..a87e88bdc 100644
--- a/doc/qbs.qdoc
+++ b/doc/qbs.qdoc
@@ -675,7 +675,7 @@
For example, a profile for building C++ applications contains at least the
installation path and the type of the compiler toolchain. A profile for
building Qt applications contains the toolchain-specific properties as well
- as the installation paths of the Qt modules.
+ as \l{Qt-specific Module Provider Properties}{the path to the Qt installation}.
This topic describes profiles stored in the \QBS settings. In some cases it
might be beneficial to keep profiles explicitly in the project sources. This
@@ -707,7 +707,7 @@
You have successfully built your first \QBS project. If you want to build
- projects that use Qt, additional steps are necessary. Please refer to
+ projects that use Qt, additional steps might be necessary. Please refer to
\l{Managing Qt Versions} for more information.
\section1 Global Preferences
@@ -754,10 +754,10 @@
\section1 Introduction
- To let \QBS know where the Qt build or Qt version is that you want to use,
- you must register it.
+ If your environment has the right \c qmake binary in its \c PATH and is also set up
+ properly for a matching toolchain, then you do not necessarily need a profile
+ to build projects with a Qt dependency. Otherwise, you should create one:
- Register a Qt version like this:
qbs setup-qt /usr/bin/qmake myqt
diff --git a/doc/reference/modules/qt-modules.qdoc b/doc/reference/modules/qt-modules.qdoc
index 638160104..df5219ccd 100644
--- a/doc/reference/modules/qt-modules.qdoc
+++ b/doc/reference/modules/qt-modules.qdoc
@@ -55,6 +55,22 @@
The Qt modules that have properties and relevant file tags are described in
separate topics.
+ \section1 Qt-specific Module Provider Properties
+ Looking up a Qt installation happens via a \l{Module Providers}{module provider}.
+ By default, if a dependency to a Qt module is encountered, \QBS collects all Qt installations
+ it can find. This lookup happens by searching for \c qmake executables in the \c PATH
+ environment variable. Alternatively, you can explicitly tell \QBS which Qt
+ installations it should consider by setting the \c Qt.qmakeFilePaths
+ \l{Parameterizing Module Providers}{module provider property}. In that case,
+ the environment will be ignored. For instance, with the following Linux command line,
+ \QBS will build the project against a custom Qt instead of the standard one in \c{/usr/bin}:
+ \code
+ $ qbs moduleProviders.Qt.qmakeFilePaths:/opt/myqt/bin/qmake
+ \endcode
+ You can also set the module provider property in a profile. The simplest way to do
+ this is via the \l setup-qt tool.
\section1 List of Submodules