When building a sub-project using the context menu -> Build, qmake was
executed every time, because the pro file in the Makefile was compared
against the root project instead of the sub-project.
Change-Id: Id76d7d23e3fa9a8e4c5c10cd10adcc945ff3b186
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If the user used a macro, the Makefile will never match it, and qmake will
be executed on each build.
Change-Id: I2790db3a788ea7971145b475781a6193a1ed0842
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
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>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Set up a better environment for initial project parsing (before Kits
are configured).
Task-number: QTCREATORBUG-19241
Change-Id: I2431113dbbe6fb6a66f95fb1efb36834fa184f3d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not unconditionally prepend QT_HOST_BINS to PATH as part of the Kit
setup.
Prepend this directory to PATH in the Qmake- and GenericBuildConfigurations
instead.
Task-number: QTCREATORBUG-18714
Change-Id: I1c1d1362105b82f9c369d989e90d4f7079c2c9a2
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not unconditionally prepend the (c++) compiler path to PATH for
all projects using GCC-derived toolchains.
Prepend the compiler path in the Qmake- and GenericBuildConfigurations
instead.
Also change the order: Apply buildconfiguration's addToEnvironment first,
only then apply the kit's addToEnvironment.
This does change a few things:
* CMake and Qbs will now get the normal PATH
* MSVC compilers will have their compiler path prepended to PATH
by the effected BuildConfigurations. This should be harmless,
since that happens before the environment setup script is appended.
Task-number: QTCREATORBUG-18714
Change-Id: I548182bc447d80d24f4de4ce7cf12ee1a753ed26
Reviewed-by: Eike Ziller <eike.ziller@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>
... instead of peeking into versionInfo().
in fact, make versionInfo() private, to avoid subsequent deterioration
as happened before (after 5e596e89d).
some other functions that use it in its interface also become private.
this fixes several breakages related to working with non-installed
prefix builds of qt.
Change-Id: Ib67de79323c9e38f3de48a09854b155de9eef5b2
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If ProjectMacroExpander doesn't resolve it we fall back to the generic
ProjectExplorer resolution, which is likely to pick the wrong project.
Task-number: QTCREATORBUG-16724
Change-Id: I201b722c5fe184905f744a1f344ec46941f92ae3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
Add setRootProjectNode method and a default implementation of
rootProjectNode to Project. Use that in all derived classes.
Change-Id: Id28cde04457a20a8963d43020785ef9d77fea57c
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
In Qt4 the force_debug_info flag doesn't work, so we won't actually get
a profile build, but only a regular release build.
Change-Id: Ie8c31f882b393e35eb525dd12392354ecbbaee75
Task-number: QTCREATORBUG-15457
Reviewed-by: Robert Loehning <robert.loehning@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Also, use the proper API for determining QML debugging support.
Change-Id: I9038fb74fcee1f87a7687343ef51e115c8a93936
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Remove QbsBuildInfo, which only adds the same information over
the normal BuildInfo.
Change QmakeBuildInfo to use the buildType as provided by
its base class.
Change-Id: Iddb86487c85893988f78bbfaf549823a19f13b5b
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
We define a Profile build to be a Release build with separate debug
info. You can thus change a given build from Release to Profile of vice
versa by toggling the separate debug info checkbox. The messaging for
future user interaction about Profile builds has to take this into
account.
Task-number: QTCREATORBUG-14009
Change-Id: I62a5b13993b20bf36329b1eefa8b1b6096f31644
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
The coupling of qml_debug to qmake's Debug profile is both brittle and
wrong. There are good reasons to also enable qml debugging in certain
Release builds and changing the build type of a specific build often
leaves the UI in an inconsistent state.
Change-Id: I89cb86849c984278ebfc54f66f139ec482b18d9a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
We don't need to support QtQuick1 anymore. Consequently, the
minimum Qt version for QML debugging is bumped to 5.0.0.
Change-Id: I9528de3f6869fb391eaf9560a148e03f6067b9de
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
That should take a couple of bytes less to store. Make sure this
change is invisible to the configuration files.
Change-Id: If5e73b52493c9164de9e342021d8153d274b350f
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Extract the whole makefile parsing code into a separate class, to
make the code more manageable. Also fix some bugs on importing additional
flags like qt quick compiler or separate debug info.
Task-number: QTCREATORBUG-13947
Change-Id: Id04bff191c188f95230274d990b1676e9b2f419d
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
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>
