Among others, this removes the wart introduced in 4d3d2d0dfb.
Change-Id: Iafa63f6e4cca327a1d1dd6a8bbcfaa10032327db
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... in handleSubDirContextMenu overload, obsoleting one cast there.
Change-Id: Ic6e8bfeee0fa2f8838a29df8123efe10f2faefd4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Now SimpleProjectWizard supports also cmake buildsystem therefore
qmakeprojectmanager it's not the best place to keeping it.
Change-Id: I383ee89ea22e8df157cd98f644d3fd971e3c2382
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The step list names are computed separately anyway, having an
extra preamble consisting of concatenated build list names on
one line looks unnecessary.
Change-Id: If754c6363042927210dfd09c23f2f494081f8c47
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Should be at least theoretically the right one, but is mainly
done to always feed a QmakeProFileNode * to the 5-args
handleSubDirContextMenu().
In practice it does not seem to impact the current level of brokenness:
In case of Build->File with not-synchronized editors the action shows
the name of the file selected in the project view, while it actually
builds the file in the current editor.
Change-Id: I47f8f22eb80be18d1be5997a861cea89bd069d1b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
No need for two manager type classes talking mostly to each other.
Change-Id: I82a52385df08dc4cddac2d294661341a79b86a4d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This allows users to work on a top-level SUBDIR project and build a
given subproject without resorting to using the mouse. Explicitly
building a subproject like this is necessary when that subproject is
not automatically built, such as auto tests when Qt is configured with
-nomake tests.
Change-Id: Ibdf18c5a0c60c53decf8bff5daa8615a1454d9df
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>
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>
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 consistency, it's straight forwards access, similar to
currentProject, not much to search and find.
Change-Id: I7ce696bdc24b6a8713d6f11e02443a6f94c605f6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... of SimpleRunWorkerFactory.
This requires being explicit about the SimpleTargetRunner worker
default, but makes the template re-usable for current users of
RunWorker::registerWorker() which I would like to phase out now,
for less variations in the RunWorkerFactory setup.
Change-Id: I32638437e5bb29f143650f5fde706711ab25accf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Adding support for CMake as well as QMake
Task-number: QTCREATORBUG-17308
Change-Id: I615b58921918ec87f935e0f11d3dd23ec20f0ac1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The infamous "build dir is not at the same level at source dir" warning
for qmake projects has gone through a number of iterations in Qt
Creator, having been added, removed and re-added, always to the
criticism of some users. Our new approach is as follows:
- The warning appears at the widgets where the build directory is
set, both in the target setup page and the build config widget.
- The warning also appears in the issues pane, but only if the build
failed.
- The user can disable the warning altogether in a newly introduced
qmake settings page.
- This option is disabled by default on Unix, because to my
knowledge all failure reports have been for Windows hosts.
This should finally please everybody.
Fixes: QTCREATORBUG-16945
Change-Id: I638be1f15e8c260a5d72047d6850a3a0f685cf03
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@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>
There are currently two types of wizards for creating auto tests:
- Qt Unit Test
- Auto Test Project
Both produce almost identical code in the case of a Qt GUI-based test,
and the descriptions are very similar. This is really confusing.
The Auto Test Project wizard has support for Qt Test, Google Test and
Qt Quick Test. In addition, the documentation only mentions Auto Test
Projects when it discusses the creation of auto tests:
http://doc.qt.io/qtcreator/creator-autotest.html#creating-tests
So let's just use that and make everything simpler.
Change-Id: Ia16c88c462744baa8df3f9e8082cbcad6ad9eb15
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
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>
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>
Enable Build File for source or header files only and
de-duplicate the corresponding code.
Before, the menus were incorrectly enabled for e.g. .pro
and .ui files also: While the menu was already hidden for
these non-source files in updateContextActions(), the
following call to updateBuildFileAction() did enable it
again.
Task-number: QTCREATORBUG-19098
Change-Id: I87f40e64ab044b33be9c465d1c5dfa36c3cf1260
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Since the rootProjectNode() containing the parsed files is now nested
under a new project node the main node needs to delegate enable/disable
decisions.
Task-number: QTCREATORBUG-17922
Change-Id: Ie7bb6d6802072a2127b32c0fe51fb25fc1c9c6cc
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
If a session contains an open file, when Qt Creator loads this session on
startup, Build File is invisible, and doesn't work.
Change-Id: Icbc918a4b74f6293d100c04bae0a070d99ce7196
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This got broken when refactoring the project nodes.
Change-Id: Iae4614f4a367cefeba3f70faaf19bc2f8994fb0f
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
- Avoids the hassle of QRC files and manually registering mime types
- Avoids performance regressions because of mime types that are
registered after mime database has been used
- Makes it technically possible to detect that a disabled plugin could
handle a mime type if it was enabled
Change-Id: I373008b1b56e9c6b4853055f20b3eeb112a6eff9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... and the need temporarily storing them by creating them when needed.
Change-Id: I930dd34bc7682f3d4fb40bd8da132f52ba32414b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This discourages storing the pointers needlessly. The items
are still easy accessible by the static ProjectTree::currentNode()
Change-Id: I3c0cd019e9fdc382afacbc9d9de3b97d5f58ae1e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Re-enable the sub dir actions from the 'Build'-menu when a none project
node is selected in the project tree.
Change-Id: I316079336850409f6cd7479310e3b3438060baf8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use class enum to shorten the FileType to quint16. This frees up a couple
of bytes per FileNode and we can have many of those.
Change-Id: I3a9ae25059690fefa15305a4268269647d6dc1c9
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
