If ProjectMacroExpander doesn't resolve it we fall back to the generic
ProjectExplorer resolution, which is likely to pick the wrong project.
Task-number: QTCREATORBUG-16724
Change-Id: I201b722c5fe184905f744a1f344ec46941f92ae3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
To HEAD of master branch. Plus some necessary adaptations due to API
change.
Change-Id: I906918223de3946ae532ae4042c2545dd53b66cc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use those functions instead of repeating code all over the place.
Change-Id: I03161663b4d5c538fb2ea667353ab7846373ad81
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
By default, we use a dedicated qbs settings dir located in Creator's
settings path, so that different instances of Qt Creator won't
overwrite each other's profiles. Users for whom this is not a concern
can now choose to use the normal qbs settings dir.
Change-Id: I0119228a48cfee430686ab51f69864866f4ba270
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
To HEAD of 1.5 branch. Also do the necessary
adaptations in the QbsProjectManager plugin.
Change-Id: Ic4c756b7f6134b9c61bad9635ac25c1e33c75825
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
The way this option works is not IDE-compatible, since the build process
changes the build graph and relies on the changes being transient simply
by not storing the build graph afterwards. This is fine for the command-
line tool, but Qt Creator keeps the build graph open and subsequent
"real" builds will finish immediately even when nothing has actually
been built yet.
Perhaps it would be possible to do the implementation differently, but
having the "dry run" option in Qt Creator is not valuable enough to
justify that effort.
Change-Id: Ic99ddef63555f6029c5857d2cfd8dc48d8a72914
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
Remove QbsBuildInfo, which only adds the same information over
the normal BuildInfo.
Change QmakeBuildInfo to use the buildType as provided by
its base class.
Change-Id: Iddb86487c85893988f78bbfaf549823a19f13b5b
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
We define a Profile build to be a Release build with separate debug
info. You can thus change a given build from Release to Profile of vice
versa by toggling the separate debug info checkbox. The messaging for
future user interaction about Profile builds has to take this into
account.
Task-number: QTCREATORBUG-14009
Change-Id: I62a5b13993b20bf36329b1eefa8b1b6096f31644
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
In ancient times we needed to support some qt versions that didn't support shadow
building. This code has been unused for some versions now, so remove it completely.
Change-Id: I311f255d6bfed6841e94c9c383bd9929d0d55520
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
- All except the one for "qbs build" were incomplete, which is fixed
now.
- The new implementation is centralized, so maintenance will be simpler.
- The command lines are also completely self-contained now, so they can
be pasted as-is into a shell with no assumptions about the working
directory etc.
Change-Id: I2c684141bcdc5c6da0e1af60ce60278fc4dcd088
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
All static functions, can live closer to related code.
Change-Id: I54c5680256c78f1d09b4bee3e8843b2f4350b75a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
Introduce priorities for build configuration factories. This way
plugins can register specialized build configuration factories, that
e.g. can provide additional build steps.
A negative priority signifies that a factory is not prepared to
handle a request, the default build configuration factory shipped by
the build system plugin will report a priority of 0. Add 100 to that
for each specialization you add (e.g. a remote linux buildconfiguration
factory would report 100, a specialization of that for mer will
should report 200, etc.).
Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Michal Klocek <michal.klocek@digia.com>
Generalize the target setup page and move it into projectexplorer
Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.
This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.
Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.
To support this use case the following changes where done here:
* BuildInfo class was introduced to describe one build configuration that
can be created by a factory.
* Factories report a list of BuildInfo to describe what they can produce.
This fixes the need for factories to implicitly create one buildconfiguration
and then create another one 'officially' to support debug and release build
configurations to be set up for projects.
* Do no longer work around factories to create build configurations.
Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
For example, C++ source files will be compiled but the build
stops before linking.
Task-number: QBS-283
Change-Id: If0573ea58b9a047980aab0fd8e4828f3d0c315b8
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
