If a step is part of a build configuration, that is used, but many steps
can be used as part of a deploy configuration.
In that case the active build configuration of the step's target must be
used, and that logic was duplicated many times.
Instead, let BuildStep::buildConfiguration take care of that logic. For
steps that are not offered for deploy configurations there is no
semantic difference, and for the others this removes code duplication.
Change-Id: I02f3bb50226590092cedcec02fce6fde9c7c6e63
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
"cmake --build ." is useful to build, clean and deploy, so offer it
everywhere.
This fixes soft asserts as a side effect when loading cmake projects with
existing "cmake --build . --target=clean" in their clean steps.
Change-Id: I39e5866f6012b9ea1153da324e4abd1cd25fea92
Reviewed-by: hjk <hjk@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Get rid of Project::buildDirectoryChanged signal as well as
Target::buildDirectoryChanged (and the infrastructure).
Change-Id: Ia749e62eec7e182e558d81115dc2a3d07b72b346
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Add a subscribeSignal method to targets and projects that will make
sure all signals of all project configurations added during the lifetime
of the project/target will get connected (if the type matches).
Use this to connect to some signal in all BuildConfigurations of
a project and get rid of code that keeps connecting to the current
build configuration.
Use Project::buildEnvironmentChanged as an example and convert its
usages.
Change-Id: I689bcebac4b191bf3f8a18765bf18eaac371c5fe
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Warn when attempting to do an out-of-source build while an in-source build
is configured. This seems to confuse cmake.
Task-number: QTCREATORBUG-18381
Change-Id: I1abd3be4129ba5af6439dcd60d16d429b93c0382
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Its a QObject, no need for QCoreApplication::translate here.
Change-Id: I3375a70fe60b66e13de6b9a99c35c85f82b9151e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
If an error occurs while persisting or updating the cmake state, the
build might continue for a while in the background.
CMakeBuildStep does not disconnect the Error/Run-Trigger when an
error is signaled by the CMakeBuildConfiguration. Instead it reports the
build as finished (with error). The BuildManager then disconnects the
output and runs the next item in the build queue (if any). However the
cmake step might still be alive and emits the dataAvailable signal which
then triggers the build process.
Task-number: QTCREATORBUG-18382
Change-Id: I956133fe8c6f7de58b9f842b231c70d24778b1e0
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Always show a test target for cmake projects. This will show even
if there are no tests in the project. But I think it is more annoying
*not* to be able to run tests via the locator when tests are available
than getting an error message when attempting that with a project that
does not have tests.
Task-number: QTCREATORBUG-18323
Change-Id: Iba85aa868cb9bfe6c3f44a7ffff620d081d3082f
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Report special utility targets like "all", "clean" and "install" from
the BuildDirManager and update UI accordingly.
Change-Id: I01d0dcfa23d5bddc124c8f9ee1040475184c9c1e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Use the RCs buildSystemTarget property when deciding what to build
with the "build current executable only" property set. This makes
the selection more robust.
Change-Id: I0dbcd764a06428b441084e6e4dc680e106c6d3bd
Reviewed-by: hjk <hjk@qt.io>
Always list a "all" and "clean" targets and remove the similar code
in the tealeaf reader.
This fixes the clean-step falling back to "all" in server-mode.
Task-number: QTCREATORBUG-17138
Change-Id: I1ce84f03c2e9829e4bb5f550c10cdef772fabf5b
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The old ones did not convey their meaning very well. In particular,
NormalOutput and MessageOutput were easily confused.
Change-Id: Ia0a8c1b1c366ab3f5c59f751b37b8b1f68f6831d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Make sure to run cmake *before* cmake --build when cmake files just
got saved. This helps e.g. when editing CMakeLists.txt files and the
hitting "Built" and "Save all" (or "Always save before build").
Task-number: QTCREATORBUG-16187
Change-Id: I16b1d02eb342a447003380946ce7a9d785476a0e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This removes 900 lines of duplicated code, some duplicated checks at
runtime and some (minor) quadratic behavior when gathering display names.
canClone(), canRestore() and canCreate() and restore() use the same
pattern. Handle that on the core side once. Leave retore() virtual to let
the ios code unmodified (which is likely not needed, later...). Introduce
'Unclonable' and 'Uncreatable' flags to keep Android package installation
and WinRT deployment (non-)functionality unchanged.
Change-Id: I0325479aff818a4038b2f241ca733b8d8cd66f2f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Do not forget to build the current executable target when there is a change
of available build targets.
Task-number: QTCREATORBUG-16131
Change-Id: I7fb0dfcd06cdbe3d23dbd194ed27fd3825068c62
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Remove the finished() signal that is (sometimes) used to report that
a buildstep is done and use the FutureInterface for that purpose
consistently.
Change-Id: Ibe5520b562b91f1a7f4fc73ee898b33b930029ec
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
...to be consistent with the capitalization elsewhere.
Change-Id: I947e2a5bff3a368ee9a456261186325821870552
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
CMake will silently ignore all but the last target (or fail to build
anything). This allows to simplify our code.
Change-Id: Ieee3931aca0788307107e2021d507073ef42a21f
Task-number: QTCREATORBUG-15928
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
...that passed to the build tool (cmake --build...)
and specified by user.
Change-Id: I0de51161b5dd700f3160f048fa6f02743a5186e6
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
The lines with "[x%] Building something" do not contain errors,
so there is no need to parse them (causing false positives to show
up).
Change-Id: Iee87deb73db9e82040cab5401b74c70be91e6191
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
This avoids creating lots of build directories as the user types
in something into the builddirectory line of the build settings.
Change-Id: Ib08a0f65e08bce104e4baf9e19fb01730d2f5f08
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Do not push the cmake running straight into the face of the user. Do it
in the background instead.
This needs some follow-up patches to become really useful.
Change-Id: I3457178b33e3f14bdeac25005a773d17abb73b65
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
This makes the class more applicable for later re-use.
Change-Id: Ic717dd63962b254fce639061f16b1ca8e12d8098
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
