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>
... by a Project::buildConfigurationChanged. That's the only case
used, and saves filtering on the receiver side. Also, the passed
bc is (in non-null) the active one, so isActive checks are not
necessary.
The null case seems to be only possible to trigger when removing
the currently active build configuration manually i.e. happens rarely,
so having it trigger an unneeded final display update on the dying
build config is tolerable, so drop the null check in such cases
to achieve a more uniform pattern.
Change-Id: I46f72e9e277767214dbd6920dd86b026a7084f46
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Updating on changes to other build config seem excessive, as the
updated details only depend the owning build config.
Change-Id: Iba86f2b56033ac55381d452dd2a435e5dda72674
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Select a better fallback target when a buildstep's target is no longer defined.
This change was cherry-picked from master branch:
9519f125e9
Change-Id: I7ef27361793125258cd2a73448d91d2561db5901
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Update the target list in the build step list widget for CMakeBuildSteps,
even when "current executable" meta-target is selected.
This change was cherry-picked from master branch:
ce7407dc03
Change-Id: Ifc1d8dc67894202eb38fe6088552797b198c7463
Reviewed-by: Eike Ziller <eike.ziller@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.
This change has been cherry-picked from master branch:
8b9821440d
Change-Id: Idc0c5fae7dfd255039b87ace77c02688cdd76e8f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This patch is not applicable to the master-branch: The buildkeys
for cmake targets have changed there.
Task-number: QTCREATORBUG-22634
Change-Id: I1c8abc42792a004bdadc893129c96e1b7ed428f6
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMakeParser used to set relative paths in the Tasks it creates.
Since is problematic: Task tries to match that relative file name to
one of the files that exist in the session.
At the time cmake runs only the top-level CMakeLists.txt file is known,
so this logic will map all the relative file paths to that file.
Make sure to write absolute file paths into tasks so that this mapping
is not attempted.
Change-Id: I4ab72df21f18d2eff27ca9a502d605e00df2ad85
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Select a better fallback target when a buildstep's target is no longer defined.
Change-Id: I7ef27361793125258cd2a73448d91d2561db5901
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Update the target list in the build step list widget for CMakeBuildSteps,
even when "current executable" meta-target is selected.
Change-Id: Ifc1d8dc67894202eb38fe6088552797b198c7463
Reviewed-by: Eike Ziller <eike.ziller@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>
