After the previous changes it was only an empty wrapper around QWidget.
Change-Id: I58dcd82d8342c7de5e2df537044f6cf3de878a67
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The step is the source of information anyway, and available at the
only place of use. No need to copy that over to the widget, neither
for keeping it up-to-date there when the mechanism is already
available in the step itself.
This creates quite some potential for the simplification of
the various createConfigWidget implementations in follow-up patches.
Change-Id: I4474665f194a1ff7c5792ad086ed53c8d3ce13e6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use the display name from the factory as default, override if needed.
Change-Id: I03519c998432fea4120b0de8b2fc2686644635f2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Qt 6 CMake build doesn't execute prepare_apk_dir by default (this is
the equivalent of install step in qmake). Since we have the target
for installing the build artifacts to android-build already present
in the CMake targets list, it's better to just use it, instead of
using another custom step just for that.
Task-number: QTCREATORBUG-24679
Change-Id: I369d6ce513f9aaf917c5fcbb3f6aa44e36b97af8
Reviewed-by: hjk <hjk@qt.io>
- the var args template for addItems was overkill creating a lot of
instantiations. Use a temporary list instead.
- allow default constructed LayoutItems to be used for an empty cell,
avoiding the use of a QLabel with empty text
- add an addRow({...}) overload as convenience shortcut for
.startNewRow().addItems({...}
- rename startNewRow() to finishRow()
Change-Id: I6d49dacbac3d7acf140ca526884ba1ceeeca2e0d
Reviewed-by: Eike Ziller <eike.ziller@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>
1. Systematically check for AbstractProcessStep::init() first in
derived classes.
2. Use setupProcessParameters(processParameters()); by default in
the base implementation.
3. Drop all re-implementations that are effectively the same.
Change-Id: I0ae54dd4909b354672a63ee56d0b7c2ea0732494
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
For convenience, and use it in some places.
Change-Id: I8f7cb502b37b2fbf4cf2d17cac9c6299558332dc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
On all code paths, this was implicit in a ProcessParameters::setCommandLine()
which was on all code paths either called directly immediately before, or as
part of ProcessStep::setupProcessParameters().
With ProcessParameters::setCommandLine() as only user, this could be
inlined there. The effectiveWorkingDirectory() turned out to be out of
place and rather accidentally working there and was moved to
ProcessParameters::setWorkingDirectory().
Change-Id: I634f6086c2324e3cbecd3e5d50e22afc722abd3f
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Inject special targets like all, test and install into the list of
targets that get reported by CMake. This makes those available in
the locator again.
Task-number: QTCREATORBUG-24064
Change-Id: I08f1232d243afbe0800c1dc308a00917c98ccf8a
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Keep internals internal, remove some unnecessary includes, add
some that should have been there.
This reduces the number of files that get rebuild when working
on CMake internals from over 1000 to about 200.
This patch also moves some code around that ended up being
in the wrong file.
Change-Id: Icd7366ac760dc85031040720418fbb16336dce9b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Rename some constants to get a bit more consistency into the
naming scheme. I am so tiered of missing a constant due to it
not having _ in the expected places!
Change-Id: Ibb5e82ea4e25ccb559352839b96c8a64394f3085
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use "flat" aggregation instead.
This is another step towards the formatter/parser merger.
Along the way, also fix some some subclasses (mostly in BareMetal) that
erroneously forwarded handled output to other parsers.
Task-number: QTCREATORBUG-22665
Change-Id: I12947349ca663d2e6bbfc99efd069d69e2b54969
Reviewed-by: hjk <hjk@qt.io>
All parsers can now have search directories, not just the GnuMakeParser.
This allows us to get rid of the "task mangling", removing another
instance where the order of parsers in the chain mattered.
Task-number: QTCREATORBUG-22665
Change-Id: Id0d55522ae6800afd9f50ff36546224b0d8bb382
Reviewed-by: hjk <hjk@qt.io>
Adapt the variable name after moving the functionality from the
BuildConfiguration to the BuildSystem.
Change-Id: I16006066841222ddd3607198413e2b55e6270c89
Reviewed-by: hjk <hjk@qt.io>
It should not be possible to trigger the condition. Except for MakeStep
the function is only called from real BuildSteps, that always live in
a BuildConfiguration.
A MakeStep could live in a DeployConfiguration, but that belongs to
a Target. That target always has a BuildConfiguration in case the
project type requires one. So not having a BuildConfiguration can only
happen when the project type doesn't require one, but then the
situation is not an error that should be notified as a Task.
Change-Id: I2a5d90fdadd3916d3dae6a0fdc6e6ab2010a8111
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and use in ProcessStep and related classes.
Change-Id: Ie6f1403d0aa2b9f5bcde06e994809466700b1357
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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 MakeSteps are instantiated when the project is opened, but if the low
priority setting is changed after that, it was not applied until reopening
the project, because the setting was only tested on the ctor.
Moved the setting test to actual execution.
Task-number: QTCREATORBUG-23048
Change-Id: Ie0bcbe07f6d9a09b173f7e0fa6f1d5d12b4ac601
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Default is false.
Task-number: QTCREATORBUG-23048
Change-Id: I0f0cc787229456aad2ddf47e4ef37bad58af2038
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This should prevent slowdown of the IDE (and the rest of the system) while
building with all the CPU cores.
Fixes: QTCREATORBUG-5155
Change-Id: Icaadc53958f2d8e918035463e3c9344c91235615
Reviewed-by: hjk <hjk@qt.io>
The Environment class is supposed to support values with references to
other variables, but we failed to actually expand them in most places.
Fixes: QTCREATORBUG-22687
Change-Id: I108cb59d3b4571471423455240f6f4f1cf64bf05
Reviewed-by: hjk <hjk@qt.io>
This lets the compiler catch issues like QTCREATORBUG-22818 and
saves visible casts on the user side.
Change-Id: I5a307a55364daa0bec039a4c38cc9827841ff9c1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The BuildStepList is no longer a ProjectConfiguration, so this
code breaks.
Task-number: QTCREATORBUG-22818
Change-Id: I7350c0520d4b82e896761a87b52ccc1d47934530
Reviewed-by: hjk <hjk@qt.io>
... for build step related widgets. These are specifig to a build step
which in turn is only interested in its own build config and target.
Change-Id: I5ec277ba279932d18a615e528acffaccdc41e307
Reviewed-by: Christian Kandeler <christian.kandeler@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>
