As for the build config, we provide a global variant for use by external
tools, and one for use in the respective run configuration itself.
Also hide the deprecated "CurrentRun" variant, which was forgotten in
b55825a420.
Fixes: QTCREATORBUG-25561
Change-Id: I51aaff10301f7ff1256abf1c09ac9f5be136ab00
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There is no gurantee that a Target has a BuildSystem.
Target::additionalData() does expect a BuildSystem.
Task-number: QTCREATORBUG-24817
Change-Id: I41edf89fa6dbf6ed24a27129b8353a9506b7b176
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Global variables with names such as "CurrentProject*", "CurrentKit*" etc
are harmful, because the term "current project" as used in Qt Creator
does not refer to the "active project", but simply stands for the
project that contains the node that is currently selected in the project
tree, which in turn may or may not correspond to the current editor
document, depending on the "sync with editor" setting. In other words,
the "current project" is almost a random value with little meaning
outside the project tree itself.
Therefore, we remove "CurrentProject*" and friends, except the ones that
are currently intentionally in use. The latter get renamed to
"CurrentDocument:Project*", so their purpose becomes clear. Their old
names are kept around for backward compatibility, but are not suggested
by the variable chooser anymore, so new usages are unlikely and we can
remove them at some point.
We also add some ActiveProject* variants that have been requested in the
past.
Also remove the "CurrentSession" prefix that was deprecated six years
ago.
Fixes: QTCREATORBUG-12724
Fixes: QTCREATORBUG-24606
Change-Id: Ibba5d0e0ce3d2beb444a5eec01fbb9b745d90a1d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It was already only one id string with two names. Since it is not
an id for the factory but the id of the created run configuration,
settle of runConfigurationId() as accessor.
The factory and id fields in RunConfigurationCreationInfo were
redundant. factory always implies (runconfiguration)id (but not
necessarily the other way round, in theory different factories
are possible for the same runconfiguration type for different
devices). So drop the id field here.
In one case now factory pointers instead of ids are compared, but
this is neutral there as this happens in a context of a fixed Target,
device and project are fixed there, so id and factory are equally
unique.
Change-Id: I859aa91486a2dd4abfc7369540a3322d6ec6260d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... redirecting to activeRunConfiguration()->buildKey()
This will allow the user code side to be moved closer to a setup
that will allow to shift the build data stored in project nodes
to the build system.
Change-Id: Icdf03e77bf61ee03b3a16855ac67652c205402fa
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... when a kit disappears.
This can easily happen, for instance due to a Qt version update via the
installer, and until now resulted in the disappearance of all user
customizations of build and run configurations.
We now store some additional data when serializing a target, and use it
to recreate a kit of the same type upon restoring. While the resulting
configurations are not guaranteed to be functional, they should contain
all the customizations, which the user can then copy over to a proper
kit.
Fixes: QTCREATORBUG-23023
Change-Id: I659d52808b2f8a308e6aa094e8ef2ee60d586952
Reviewed-by: hjk <hjk@qt.io>
Changes of active run and build config impact some visible state, but
instead of connecting and disconnecting signals to the target, make the
call explicit.
Also, triggering only updateAction is sufficient, as this will already
run updateRunAction. This makes the number of doUpdateRunAction calls
when opening a normal QMake project with one target, three build configs
drops from 17 to 15.
There was some mechanism on the receiver side originally meant to
prevent excessive updates, which broke with 7ae3589 when remembering the
previous configurations was accidentally removed.
This here drops the mechanism completely, as active changed signals
would not trigger twice in succession for the same config anyway.
Change-Id: Id9f87e542d8871733966ab79118734b7e9ad1e8a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Architecture-wise, this now means that Target knows about the
MiniProjectTargetSelector, otoh, Project does less, and quite
a bit of signal, slot and qobject_cast is gone.
Change-Id: I0feef9328144282c7c4ca710a12ac0e495810684
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by MacroExpanders in Build and RunConfiguration. Deploy didn't
use its own, BuildStep always composed an empty expander with
the BuildConfiguration's, uses now the BuildConfiguration's expander
directly.
Change-Id: I9de51bfc32aeb3d73f4974175e42a37807e49ac1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
That is, instead of what is specified in the project files of the
respective build system, let the user manually set the data in the
deploy configuration.
This is intended as a last resort for use in project managers that are
not able to deduce any deployment information from the project.
Fixes: QTCREATORBUG-21854
Change-Id: I2fefb89a4aa846e52aeca69749ca03534f4f0a67
Reviewed-by: hjk <hjk@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>
... when restoring a target.
The run configuration may not have its default display name yet, in
which case all but the first restored run configuration would get a
number as its display name.
Fixes: QTCREATORBUG-23123
Change-Id: I5068cb85b67166357e0a88fb9638131a24e1340f
Reviewed-by: hjk <hjk@qt.io>
If the deployment configuration contains an "install into temp dir"
step, then the local file paths of the binaries built by the build tool
will not be in the list of deployable files, because all deployables
come from the temporary install dir. Therefore, look for just a file
name match as a fallback.
Fixes: QTCREATORBUG-21235
Change-Id: Ie3fad515515b4f28cc6bdef1254f4c05a0557569
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by a Project::buildConfigurationChanged. That's the only case
used, and saves filtering on the receiver side. Also, the passed
bc is (in non-null) the active one, so isActive checks are not
necessary.
The null case seems to be only possible to trigger when removing
the currently active build configuration manually i.e. happens rarely,
so having it trigger an unneeded final display update on the dying
build config is tolerable, so drop the null check in such cases
to achieve a more uniform pattern.
Change-Id: I46f72e9e277767214dbd6920dd86b026a7084f46
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The only listener left is the target's project, which is known at each
emitting location and can be called directly.
Change-Id: If07d2c1c43fcf5d2094c0b6d59f773d12b4f6d6b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... before announcing it and trying to remove it a second time.
Change-Id: I0f0238974fa317051d99b8f096cfc472e4f0cbe3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The models hold essentially duplicated information besides the actual
configuration lists that are already in the target and are only
used in a context where the target is known and accessible.
As the models keep track of all added or removed configurations
and can be fed configurations of the right types only, the need
to filter is gone.
Change-Id: Iec2c6879223893297c71e7632310ac526b704237
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... with a suitable default implementation accessing a member
populated at construction time instead of walking the parent
chains on each access.
Change-Id: I58dae6da80ed0b023cc603fca13a5a205b123672
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This prodecure requires no further information from the specific project
managers, so we can start it from the ProjectExplorer itself.
Also wait until after project parsing has officially finished and the
run configurations have updated their "enabled" state. Otherwise,
RunConfiguration::isEnabled() will always return false, potentially
leading to the active run configuration getting switched
unintentionally.
Fixes: QTCREATORBUG-21692
Change-Id: I32f4f758b5baa6222329d07b811993568eff1ee3
Reviewed-by: hjk <hjk@qt.io>
This provides correct deployment information as seen by the build system
when Qt Creator cannot retrieve it directly.
It's most useful for autotools and cmake projects, but can also help
with qmake in certain edge cases.
[ChangeLog] It is no longer necessary to provide a
QtCreatorDeployment.txt file when using CMake projects with remote Linux
devices.
Fixes: QTCREATORBUG-21855
Change-Id: I27e07a45dd1565e489f4b573cc3fff8191c57d9b
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This is mainly there to make the local runconfiguration implementations
more uniform. Both qmake and qbs will drop runconfigs for builds that
are not available anymore, so that's a no-op for them.
Change-Id: I8aa32d779f67cce7a4d4733cfbe0c9a136bfd3f7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
A convenience wrapper for
applicationTargets().buildTargetInfo(buildKey),
the only context using the BuildTargetInfoList member.
Also, only one of the free comparison functions is ever used,
only in one place. Inline it there.
Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... 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>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There's a 1:1 relation between the involved types, having either
the factory or the id implies having the other. So shorten interfaces
that used both so far. Also canCreate() == canHandle() && id matches,
so use that directly.
Also drop/QTC_ASSERT former canHandle() checks that are implicit
in preceding ::find() calls.
Change-Id: I686ea5774c5a01b05b3b4882b3d59080a812a677
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Similarly to before, it's either an empty list, or a single id.
So use a function with bool return saying whether an id is returned
and a plain accessor the the id.
Change-Id: Ied2900f23bdb4c264d9fb1944c60bed734d1d8bb
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Let's enable all build system plugins to provide this information.
Task-number: QTCREATORBUG-20810
Change-Id: I0ef953e3c2c9a2be1fc4187e93232e9a2aeacafd
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Use unique_ptr for all *Private classes, except for those
in singletons.
Change-Id: Ib56c31ddedc6e9cf321f15de1f1e697a27ad4089
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Casting all elements of a container, similar to qobject_container_cast.
Change-Id: Ib455fe8c7fa0d4acda7e29685c3100638a0152f8
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
