To match better with the rest, especially the base AspectContainer.
Change-Id: Ide0966cab3219800aa6b7b9e6012731a3fbe7a6f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Remove emitting 100% progress on finish, as that's
done automatically by the task tree.
Task-number: QTCREATORBUG-29168
Change-Id: I468fd2c12ffda4c051a46e586fc18214598269f9
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Provide a setDoneHook() setter instead. The hook is
introduced temporarily, as when all the subclasses
are transformed to use the task tree, the done hook
is going to be a part of the subclass' recipe.
Task-number: QTCREATORBUG-29168
Change-Id: Idbc0f8b8a32c8df2fa5ecb73ed1cbaedad99620d
Reviewed-by: hjk <hjk@qt.io>
User configurable, on by default (only) for cases where build and run
device are different.
The staging dir is by default a randomly named directory on the build
device, but can be changed by the user if needed.
Overall, this does not change anything for a pure local setup (but
would let the user opt-in into staging, too)
Change-Id: Ic1c5fd1f1261e067692710c9e3aa9d821897478d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This commit adds a "CMake Install" deployment step, which is using
"cmake --install" command.
"cmake --install" command has been added in CMake 3.15, this is why the
minimum CMake version has been updated to 3.15.
Note that CMakeBuildSystem::makeInstallCommand is still using cmake --
build --target install due to a CMake bug regarding "Ninja Multi-Config"
generator, which doesn't intall all binaries via "cmake --install".
Fixes: QTCREATORBUG-25880
Change-Id: I504674c380055d8ef136d344a78b80c17ecf9765
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Merge processSucceeded with processFinished into one virtual
function. Leave default implementation empty, so that
reimplementations don't need to call base impl. Move
processFinished into private section. Pass just one bool success
parameter into processFinished.
Change-Id: Ide3e262de0c0c5583c9fec2426fa460b6b74a49d
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
By default xcodebuild does not try create / download a provisioning
profile for a project if a valid one does not exist locally
in ~/Library/MobileDevice/Provisioning Profiles, even if the
Xcode CODE_SIGN_STYLE attribute is set to Automatic.
Starting with Xcode 9, xcodebuild accepts a new
-allowProvisioningUpdates option.
When passed, xcodebuild will request a new provisioning profile
from Apple's servers for the current project and use it during
the build. The provisioning profile is only needed when building
for a real device, not the simulator.
When building an iOS project with qmake, the option is embedded in the
wrapping Makefile generated by qmake, so Qt Creator can simply call
make (which it does).
For CMake, there is no wrapping Makefile, so we need to pass the new
option explicitly as an additional build tool argument.
There might be cases where automatic provisioning is not desired,
which is why there is now a new checkbox in the CMake build step
configuration widget. It's default value is 'enabled', to match
qmake's behavior.
As an implementation detail, isiOS had to be moved to a header file so
it's accessible to both the build configuration and the build step.
Fixes: QTCREATORBUG-26246
Change-Id: Ic80cd965ba095d0ff379e13ad2ffb8c298c9f7c4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
CMake has multi-config generators like:
* Visual Studio
* Xcode
* Ninja Multi-Config
The first two have different special targets for "all", "install",
"package", "test" namely: "ALL_BUILD", "INSTALL", "PACKAGE",
"RUN_TESTS".
All of them need to get the build type passed via "--config <build-
type>" and not via "CMAKE_BUILD_TYPE".
The multi-config generators will use only one build directory.
Fixes: QTCREATORBUG-24984
Change-Id: I8aa7ff73ce2af1e163b21a6504d26fcf95530edf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
After the previous changes it was only an empty wrapper around QWidget.
Change-Id: I58dcd82d8342c7de5e2df537044f6cf3de878a67
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
- Store the selection of the "Current executable" target again
(broke apparently with 2c822ae3)
- Display the resolved target of the "Current executable" seletion
in the command line, instead of the fixed "
'<Current executable>' text
- Make the "Current executable" translatable
- Add a tooltip explaining what it is
- Use a Utils::TreeModel instead of a QStandardItemModel for the
target model
- As side-effect, searching in the target view using Ctrl-F seems
to magically work again.
Change-Id: Ia4d0913f6e586f49f74da66651a9177437dad6d9
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This is actually a slight change in behavior insofar as
the summary now uses the same environment as the build
itself. This should not matter, or even be more correct.
Change-Id: I48e5be6cb7b97606f80f563ba399c4b6ff61c3bf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Using a dedicated OutputLineParser ensures that we only ever see
complete lines and thus prevents "partially red" lines in the compile
output pane.
Fixes: QTCREATORBUG-24209
Change-Id: I12b3de70b81789afe727b66e366facdcc81f8ab8
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
CMake supports this for a while now.
As a side effect this fixes QTCREATORBUG-23738, which was caused by the
radio button hack used to show that only one item could be selected at
a time.
Change-Id: I18cbe6c5ee3872edaf74b9d828bde1ac5bf63563
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add a way to provide options to cmake --build in addition to the
already existing option to the build tool (separated by -- from the
cmake arguments).
I decided to have these two separate to ease upgrading from older
Creator versions.
Task-number: QTCREATORBUG-24088
Change-Id: If989f9942498055312ba0e11e7d80c2b5ece269d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This amends commit b15d1951a2, where we moved the line splitting into
the output parsers, but overlooked that the CMakeBuildStep does
additional line-based parsing. As a result, the stdout -> stderr
redirection for ninja output was broken.
Change-Id: Iafbbce9a3f9c0383812a9e4c129c1d94fa907b73
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Now only one piece of code needs to be written to both linkify output in
an output pane and create tasks for it in the issues pane.
The calling sites are also simplified. For instance, until now, build
steps had to feed their output parsers manually and then push the
created tasks up the signal stack in parallel with the actual output,
which the build manager relied upon for cross-linking the output pane
content. Afterwards, the output would get forwarded to the formatter
(and parsed for ANSI escape codes a second time). In contrast, a build
step now just forwards the process output, and task parsing as well as
output formatting is done centrally further up the stack.
Concrete user-visible improvements so far:
- File paths in compiler/linker messages are clickable links now.
- QtTest applications now create clickable links also when run
as part of a build step, not just in the app output pane.
Task-number: QTCREATORBUG-22665
Change-Id: Ic9fb95b2d97f2520ab3ec653315e9219466ec08d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Allows to use constants in fewer places, similar to what e.g.
RunConfiguration does.
Change-Id: I9d049128206c4acf0ce14b06b66d6c090a7c5242
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use radio buttons to select build targets in CMakeBuildStep.
CMake only allows for one target to be built at one time, so checkboxes
are confusing.
Task-number: QTCREATORBUG-20764
Change-Id: I1171abd1753817595562526456c3ce613a22667c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
That method makes little sense, considering that there can only ever
be one build target.
Change-Id: I53d555fa7d713dd8c05b4a9f5944908afeee859f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The only user can also get this information from the relevant
CMakeBuildConfiguration.
Change-Id: I80e176ef0a8bc427f6adbf75b20e29f38d7b949f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
First step, move {DesktopQt,Qbs,CMake}RunConfiguration{,Factory}
into the same new files.
This only moves down to QtSupport, not ProjectExplorer, as there
are in all three cases direct dependencies on QtSupport. Long term
I would expect them to move further down.
Change-Id: Ib16b19df7f3f642ed7f7db89a1f6904601d976ba
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Add a helper method to find the default build target for a CMakeBuildStep
based on the BuildStepList the step is part of. Use all/install/clean
targets as appropriate.
Change-Id: Idc0c5fae7dfd255039b87ace77c02688cdd76e8f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
When first loading a CMake project, if parsing fails all targets get reset
to the "all" target. Most commonly users will notice this when the "clean"
target gets reset to "all", and can often go unnoticed for a while. This
can become especially annoying when custom target configurations are used.
With this change the previous targets will be preserved upon failure.
Fixes: QTCREATORBUG-21617
Change-Id: I52a3a2c472c7b8d98bc016b1e55a202147fc091c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The extra parameter was always computed but used only in one place,
and that use got removed lately.
Change-Id: Ie10c0107ca70ee97ce03f83294992aab8d1a3ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Default to false, remove all no-op reimplementations.
And rename the getter to isImmutable according to the rules.
Change-Id: I8cce79d88fb59badfa1cffcf30a46f7ff3b09e8b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
From a virtual function to a normal one backed by a real data member.
That's essentially what several re-implementations did, the other
ones used a fixed value instead.
Change-Id: I61e45f1d4f7f0f80fe2eb1f2729785f37e7bb803
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use BuildStep::displayName() as default.
This probably could be the only possibility, but currently there
are some discrepancies that are kept in this patch to make
the patch mechanical.
Change-Id: I2a1e5c2ff37ad95e25309eb16e07099e42191f60
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
