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>

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 @@
     \endcode
 
     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:
     \code
     qbs setup-qt /usr/bin/qmake myqt
     \endcode
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
 
     \table