Cleaning up a mess with different environments being used at different
places.
Change-Id: I038c440c78e7c195d0154d1642d2573af56008b2
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Both the configuration widget and the build itself were complaining that
a tool chain is needed, even though the build in the end cares only
about the make command, not the tool chain.
Change-Id: I5be0f44376a446bd76053f5365c842384d71be30
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Unify generic and autotools make steps, by moving the better maintained
logic from the generic make step to the base make step.
Add fallback code for restoring settings from previous autotools make
steps, since a key was named slightly different.
The autotools make step was behaving a little bit better when there is
no C++ toolchain set in the kit, but on the other hand would just take
the make command from a random existing toolchain, which can be wrong
too. Anyhow, this must be fixed in a follow-up patch for all make steps.
Change-Id: I47af7d327feb9336790d30c8b9a4968c25b25db3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
So provide it through the base class, also for the factories.
Change-Id: Ie4a6113b785ec6c0ddde694ec0bcd11a26331c39
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
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>
There are two differences that get introduced by this change:
- The configuration widget checks that there is a build configuration,
but not if this build configuration is a QmakeBuildConfiguration. This
should not matter, since Qmake is still the only supported project
type for the qmake specific make step
- It removes the automaticallyAddedArguments(). As far as I can see this
never had any effect anyhow, though. They were never actually added to
the arguments.
Change-Id: I73be227a32117e462def38bdd040dbd7cbcc113f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The new summary is similar to the one in the qmake make step, adding the
working directory to the summary text, and adding checks for tool chain
and build configuration etc.
Different to the qmake variant is that it doesn't restrict to any
particular build configuration type, and that it needs to show
allArguments() instead of just userArguments().
Change-Id: Ie79264267a2ce834a3d3ffe2e4c066786642adc1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Variables are already supported, just the chooser was missing.
Change-Id: I3a0d64c6a954a8180a388b6dda8c94af11a6daba
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Similar to the make step from qmakeprojectmanager.
There is an internal semantic change when there is no C++ toolchain: Now
the effective make command will be empty in that case. Before this patch
it was defaulting to "make", but init() was never using that because it
also checks for an existing C++ toolchain, so there is no visible
change, and actually more consistent now.
Change-Id: I31157fee63c465b4b61701d76152f3ad172c29e8
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As a first step of creating a generic base for the 3 existing
implementations.
Change-Id: I2456db74cb635316f97a247e2a2b6bdb34931440
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
