... availableBuilds() and availableSetups().
Goal is to merge them and inline all the local createBuildInfo()
functions.
Change-Id: I9f19093163808b6da6dc83977894420e08a1edd9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Essentially a proof-of-concept that knowing the actual classes is
not needed.
Change-Id: I82b1664c93a25e418860bda77f66ec77144cf658
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and use the autotool configure step as guinea pig.
Change-Id: I0bbc9fee70b3c8626eb0dec0f728e8368f860484
Reviewed-by: Christian Kandeler <christian.kandeler@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>
This is getting repetitive.
There's a new connect too, that's not wrong in the current two uses
and will be helpful in the upcoming Qbs one.
Change-Id: I4a4923a43937922c66be1f73822103b1e3e7b077
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The extra inheritance level is not needed (and used nowhere else), and
all special default arguments can be determined from the kind of build list.
Change-Id: I5ab9987d7b1fd8e5999b7c4c8796c2c24db03821
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Less code. And there's more room for consolidation.
Change-Id: Iccdaf5570155ec2783b7cf6528d3887f6efd5dbb
Reviewed-by: Christian Stenger <christian.stenger@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>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... to a place where the potential receiver already exists.
It had not even a chance to work before.
Change-Id: Id6ca2fe522636dcd03b81c5da513f48549b8eb76
Reviewed-by: Christian Stenger <christian.stenger@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>
To avoid repeating the 'MimeDatabase mdb; mdb.something(); ' mantra
all over the place.
Change-Id: I4bfef62e73275a991455141671d6071162788e9d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... and adjust users in Nim and Autotoolsplugins.
Change-Id: I6133ca933a5a4dc4d7d9ff73c8ca7afaa51ae516
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use those functions instead of repeating code all over the place.
Change-Id: I03161663b4d5c538fb2ea667353ab7846373ad81
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Use pragma once
* Make sure overrides are everywhere
* Clean up code here and there
* Remove useless code from initializer lists
Change-Id: I9c285a803ea36cb32d14b3335757fd4b57f27d02
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
So that the un-changed optimization in setBuildDirectory works
correctly.
Change-Id: Ie31fb2722c663cd0f998458d536181f47c83a37d
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
In ancient times we needed to support some qt versions that didn't support shadow
building. This code has been unused for some versions now, so remove it completely.
Change-Id: I311f255d6bfed6841e94c9c383bd9929d0d55520
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: I919da493d0629b719d328e5e71c96a29d230dfd1
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
configure is called using a relative path from buildDir
to the project directory and the configure command line
is updated to reflect changes to buildDir.
Change-Id: Ia9e8eef446efd21b6dcedef4668ff03adfd8a20c
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
Introduce priorities for build configuration factories. This way
plugins can register specialized build configuration factories, that
e.g. can provide additional build steps.
A negative priority signifies that a factory is not prepared to
handle a request, the default build configuration factory shipped by
the build system plugin will report a priority of 0. Add 100 to that
for each specialization you add (e.g. a remote linux buildconfiguration
factory would report 100, a specialization of that for mer will
should report 200, etc.).
Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Michal Klocek <michal.klocek@digia.com>
Generalize the target setup page and move it into projectexplorer
Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.
This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.
Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.
To support this use case the following changes where done here:
* BuildInfo class was introduced to describe one build configuration that
can be created by a factory.
* Factories report a list of BuildInfo to describe what they can produce.
This fixes the need for factories to implicitly create one buildconfiguration
and then create another one 'officially' to support debug and release build
configurations to be set up for projects.
* Do no longer work around factories to create build configurations.
Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Indicating that new widgets are indeed created.
Change-Id: Iccc5e1e99f536fdfb0718f252a23f498053ad3a3
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Which simply returns a BuildEnvironmentWidget. A long time ago
BuildConfigurations had no environment, nowdays they do. So it makes
sense for all BuildConfigurations to have the BuildEnvironmentWidget.
Change-Id: I824c45df79a0dcd2b624bf67a4730fb5dab098bc
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Which asks each KitInformation for their parser, thus currently creating
a toolchain + qt chain if that is applicable. Remove all code that does
that by hand from various buildsteps/buildconfigurations.
Change-Id: I79a07ffd1dbe9a43bdbc838bc0098071aa412009
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
* Rename profiles to kits.
* Update some strings:
* projects mode has a Kits tab, not a Targets tab.
* " Settings" was dropped from the sub-tabs of the Kits tab
* menu entry "Build/Open Build/Run Target Selector" was renamed
to "Build/Open Build and Run Kits Selector".
* Use "Kit" instead of "Target" in miniprojecttargetselector.
(The class was not renamed as it does indeed select targets,
not kits)
Change-Id: I0727e086e2dfa0e8aaaf89fdc6f2e3596c7a4314
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
