It's not an *I*nterface anymore
Also, remove the in-all-but-one case unused QObject parent and the
object name that was only there for debugging purposes. The class
type serves the same purpose in the debugger.
Change-Id: I0dafb01e6b4fd7c7df04a63aaa3ef3e4bd693f6f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Make sure the Qnx RCs only get triggered for qmake-based projects and defend
against broken set-ups using QTC_ASSERT.
Task-number: QTCREATORBUG-19755
Change-Id: If64b73de49b0199308f767151d68909dc8b1bc53
Reviewed-by: hjk <hjk@qt.io>
Instead of calling twice for AutoCreated and UserCreated, call once
and record to which case it belongs. Only the 'both' and
'user only' combination are ever used.
Change-Id: I9c15085bcbb4bf6584a6156135f2084dbfc51c1c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
All the KitInformation methods need to gracefully handle a kit that is
a nullptr. Ensure this is indeed the case.
This might fix the actual trigger for QTCREATORBUG-19469.
Change-Id: Id78ac8a26c1be908f41a425ff1935b86888e4b8b
Reviewed-by: hjk <hjk@qt.io>
Do not override the displayname/default displayname when restoring
CMakeRunConfigurations.
Task-number: QTCREATORBUG-19762
Change-Id: Idf5e90e017a363444387e9c22812ad501aabc75b
Reviewed-by: hjk <hjk@qt.io>
Some cmake generators create a set of different configurations of the project
at the same time (e.g. Visual Studio related ones). These typically contain
the same set of files.
Creator iterates over the configurations and adds files to the project tree.
For multi-configuration generators this does lead to the same file being listed
several times below a target (the targets themselves were already deduplicated!).
This patch adds deduplication of file paths already listed in the target's
subtree of the project, thus fixing the multiple files issue. New files (e.g.
those that get only built in debug/release mode) will still get added as before.
Task-number: QTCREATORBUG-19020
Change-Id: I5dd6012ea335d9946c78c25be258c8c4d60698f2
Reviewed-by: hjk <hjk@qt.io>
Kits are a central concept and structure in anything build and run
related in Creator, their organization is crucial for the functionality
of Creator and deserve to be emphasized over other, often more cosmetic
settings.
This is the first step of two, the second step would be moving
the Device (list) page also in this category, possibly after some
reorganization in the Device category.
Change-Id: I4abc89472d0575c691fc9e5051397833126e5456
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The build list names are always the ones determined from the
build list id. No need to do that on the caller side.
Change-Id: Icc21ef355de535af21215819fe04daa76fed0d9c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
These paths are controlled by ICore.
Add ICore::installerResourcePath() to replace constructions with
settings(SystemScope)
Replace constructions with settings()->fileName() by usage of
ICore::userResourcePath().
Change-Id: I5a9fa9d09f2563c39dc5d11a4586da825c62f9ac
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... including build target name and display names instead of
returning QString build target names and producing display names
via displayNameForBuildTarget()
This is a mechanical intermediate step on the road to use
Target::applicationTargets().list uniformly as source of build
targets.
Change-Id: I7b0b1fb398d5061b0cec0b86890f9eaf0bb53a19
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Omit QLatin1{Char|String}
* Use member initialization
* Use range-based-for
(and fixed the cases with non-const Qt container)
* Sort includes to common style
Change-Id: Ibc33a732bb153862efd6d5febfac758229cb61d4
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There's nothing Qmake related in there (anymore?).
Change-Id: I8842d4824065cf3cba61d50b6f333ec3b52e3851
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Do no longer expose Nodes from the SessionManager's API. These are now
exclusively handled by the ProjectTree.
Change-Id: I585c2ac919462073870363436e767640775d9045
Reviewed-by: Eike Ziller <eike.ziller@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>
Make Project::files take a standard function to match files with instead
of an enum (and a std::function).
Change-Id: I6a24e40dba0e972ff96c0a57e775d2377e2545e0
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Link is a common class and is used across the plugins.
Change-Id: Id92e47e1b8604316ca8b970804e57abaf404ec28
Reviewed-by: David Schulz <david.schulz@qt.io>
This shifts the resposibility of creation/splitting of RunConfiguration
ids into what are essentially "type ids" and "build targets" to the base
implementation, possibly opening the path of abandoning the mangled ids
in favor of explicitly storing their constituent parts.
Take advantage of base id split in RunConfigurations for availableIds
/displayNameForId and for canCreate/canRestore/canClone.
Change-Id: I19fefb32757407ab5053a2ae0e5a79438659f6ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Add QT_INSTALL_BINS to PATH on windows in the CMake RunConfiguration.
This should fix cmake applications using Qt not being able to get
started after they were built.
Unfortunately this patch is not a great solution: This should be configurable,
similar to the "Add libraries to LD_LIBRARY_PATH" checkbox we have for other
OSes and build systems. Such a change is unfortunately not acceptable at this
stage of the 4.5 branch though.
Task-number: QTCREATORBUG-19354
Change-Id: Ic2d568d965e41e3eb875fed8c2e5dd2ba15d2db1
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Hide nodes from project list so that they will not end up cluttering
the locator with directory locations (which creator can not open anyway).
Task-number: QTCREATORBUG-19346
Change-Id: I78d7d16b7cdacf5536e81c5001a292af0bd0c2df
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This lead to <Headers> entry being missing from the project tree.
Task-number: QTCREATORBUG-19333
Change-Id: Ice3bab6d92aaa3799e66800cbae0bacd57537322
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
All RunConfiguration factories had some kind of canHandle(Target *)
implementation. Centralize this notion.
Change-Id: Ie24a355e857bddfd76b866859b8c7a42ffc83840
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
