Preparation for an additional simpler test configuration
which needs to have the same common base.
Change-Id: I1800ed5d7301f1aea99eba6ef588a204697bd569
Reviewed-by: David Schulz <david.schulz@qt.io>
If there are more than one target for a run configuration
we ended up in the first matching.
Tests may use different environments to test different things.
If the user tried to handle this by using a modified
environment for different targets failed even when the
correct target was selected.
Change-Id: Ie954c985969ffd187fe60b4ecb86aa2717d559f1
Reviewed-by: David Schulz <david.schulz@qt.io>
Do not access list items if there are none.
Amends 502ad9badb.
Fixes: QTCREATORBUG-24421
Change-Id: I2982f675bba36eac98cb116acf64472a9f415977
Reviewed-by: hjk <hjk@qt.io>
Ensure all possible project parts are taken into account
when gathering build system targets.
When having multiple possible build system targets for a
test - which may easily happen e.g. when defining tests
beside the main application inside a big top-level
CMakeLists.txt - let the user decide which one to run.
Fixes: QTCREATORBUG-24268
Change-Id: Ia7b7e4148fe8e8dab55832c435f12cc78f5c2f7a
Reviewed-by: David Schulz <david.schulz@qt.io>
... and TestConfiguration. This allows dropping code that
reconstruct framework ids and framework lookup by id.
Change-Id: I0bb1e6e135376e21f96b9fab7971aa097787e483
Reviewed-by: Christian Stenger <christian.stenger@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>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
* use nullptr
* override
* remove old style casts
* fix most of the code model warnings
Change-Id: Ia08e846f9326ae28ca7e7d66748e25a8b817b9b1
Reviewed-by: Xing Xiong
Reviewed-by: David Schulz <david.schulz@qt.io>
If the startup project or the current active target changes
while tests are running strange things can happen as we rely
on these both being unchanged from triggering the run.
Explicitly check for these being unchanged and cancel the
test run if necessary.
Change-Id: I506c7b1c0ca4b6ea31559556f6141fe9276d0ad0
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
The build system targets no more contain the additional
pipe character. This patch fixes some 'guessed config'
warnings.
The check for the build key can now also be done
without restriction as it is unique nowadays not only
for Qbs builds.
Change-Id: Ic4e62d678c2188d0591c618cdcc156580b40b834
Reviewed-by: David Schulz <david.schulz@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since bc698d4ce6 the build system targets / build keys are
unique on their own.
Simplify the completion of test configurations and improve
readability.
Change-Id: I258e8a35a4740dd58b1365498ca399258092e0e3
Reviewed-by: hjk <hjk@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Especially when using CMake based projects in combination with GTest
we might have lots of build targets defined inside the same
'project file'. Overwriting the already assigned content is purely
wrong. Instead handle each found build system target on its own.
Task-number: QTCREATORBUG-17882
Task-number: QTCREATORBUG-18932
Change-Id: I3297a9e1da8ae4186fd4267e3485368b1a059314
Reviewed-by: David Schulz <david.schulz@qt.io>
If we already had a correct executable we might end up using
the wrong one when trying to complete the configuration again.
So, if the former configuration already had an executable set
do not try to complete the configuration again.
Change-Id: I270be71d87b311c6a5eaad14e0d5a2de60353e5d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
There are several complex project layouts that lead to failing
to determine the correct runnable for tests.
If this happens prompt the user for the runnable to use instead
of performing wild guesses or blindly using a wrong one.
Task-number: QTCREATORBUG-17882
Task-number: QTCREATORBUG-18922
Task-number: QTCREATORBUG-18932
Change-Id: I1575f310c450e56c087f1e689d0fc7dfb0cd0bef
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
If we have not found a local executable any further processing
is not necessary as the outcome will be the same: we will not
be able to start the test runnable.
Change-Id: Iaa4bbd533ced6184148f941c1cba394f9f47554d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
If we cannot find the respective build target to execute
tests, but we only have a single build target then
we now assume that this will be the right one.
Change-Id: I0f7c3c4f371bce3a7f328e7c28dc61cadf7f6e9e
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Move used enums more central to avoid duplicating
information and unify their usages.
Change-Id: I33e9bdc11f7da16ecabf03991b5a5f550a53bdad
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Replace some members by a single one.
By using the StandardRunnable we automatically get more
information that can be used later (arguments, device).
Change-Id: Id2afb6dffc27d97da568372f6ee13c7181fc393a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This might help to figure out what is wrong if we are
not able to determine which run configuration must be
used or if this determination goes wrong.
Task-number: QTCREATORBUG-17882
Change-Id: I6f1dc573b4a8c07035fa521d056ccde890f07142
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Base the selection of the run configuration on the executable
we have gotten already from the BuildTargetInfo and take
deployment information into account.
This also reverts cce1e130 partially and avoids
stuffing unrelated information into the buildsystemtarget.
Change-Id: I3de6e910a5fd1092d428ec4afc33c4ca62daaa25
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As we are still constructing build system target to compare with
on the test runner's side instead of getting the complete
information from the run configuration we ended up using the wrong
one in several circumstances. Avoid this by using the executable
information we already got.
Task-number: QTCREATORBUG-17783
Change-Id: I40431bef228f7070109297873c472fea410dbd16
Reviewed-by: David Schulz <david.schulz@qt.io>
If project files are not mapped 1:1 to targets the result
of the chosen executable was more or less random.
Try to handle multiple targets as correct as possible by
checking for build targets already where we still know
which files are part of the respective test cases.
Task-number: QTCREATORBUG-17783
Task-number: QTCREATORBUG-18357
Change-Id: I82dcc26bf52c9918e2727b439a719af08879ef49
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If a test case cannot be started or does crash while executing
these information might help to sort out configuration problems.
Change-Id: I406d5e69475d05931d4c4c4738f8528c6d74c585
Reviewed-by: David Schulz <david.schulz@qt.io>
Amends 124efb32 - this special handling got lost between patch sets.
Change-Id: Ic94145d3310668f1c63abe5443e0d833850227a7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Use information provided by the codemodel and the run configurations
as much as possible to avoid guessing.
This also fixes running CMake based tests from within the
AutoTest plugin.
Task-number: QTCREATORBUG-17882
Change-Id: I5639fa947fa602b76faf50e9b58d7a74af4e1f9c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If there is no working directory explicitly set inside the run
configuration we end up using the current working directory of
Qt Creator.
We normally get an empty string if not having modified the respective
target ourselves although you can see a default working directory when
opening the respective target for the first time.
Task-number: QTCREATORBUG-16715
Change-Id: I6e16fd4f9b15759793653a6c229c44a1be2b7739
Reviewed-by: David Schulz <david.schulz@qt.io>
Respect different location if tests are installed
before executing.
Task-number: QTCREATORBUG-16638
Change-Id: I2d154e26cdd0f28bd51e7a885c5486d36af38a68
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Guess the config if no matching run target was found.
Change-Id: If70881cd64ab6523bbca13b1c8c18d63e9fcdeb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This adds another context menu entry for items on the test tree
to allow debugging of a single test.
Task-number: QTCREATORBUG-16070
Change-Id: I98f56b0f22c94ad71f0b91d690383043ed27f1c7
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
...into files and respective sub folders.
Change-Id: Ic80d693bd73993a6e74b6d422349e47276e8cb6e
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
