Report project-specific warnings about the kit used in Project Mode.
E.g. a python project should not complain about missing toolchains,
while a qmake project should.
Change-Id: I5ce6742683cdeffc7ff3f1a3e8f0b89aee9aa0b4
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Move the emitParsingStarted into a location that is called
from both methods that had it before.
Also add an QTC_ASSERT into incrementPending, which is
triggered by the qmake parsing code directly. If something went
wrong before, then the signal will be sent anyway and in the
right sequence -- although the start signal is a bit late at
that point.
Task-number: QTCREATORBUG-20203
Change-Id: I64611e471d1e4959d5cfe0118223594a04238433
Reviewed-by: Eike Ziller <eike.ziller@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>
This prevents a soft assert from triggering.
Change-Id: Ic2b650f1c850d87492bad8f23d200ede0de35722
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The strings remember in which file they were created/assigned.
However, this used a non-counting reference to a ProFile, which could
become dangling. If a subsequent ProFile re-used the exact same address,
a string's source would be mis-identified, which would be fatal in
conjunction with discard_from().
Since we actually need only a unique id for comparison, let's use an
integer for that.
comment on cherry-pick: this is actually a lot more than a cherry-pick,
because the file ids need to be aware of the dual VFS which was
concurrently introduced on the qtc side.
Started-by: Simon Hausmann <simon.hausmann@qt.io>
Change-Id: I395153afaf7c835d0119690ee7f4b915e6f90d4a
(cherry picked from qtbase/190aa94be7f5e146bef44862b974d733755cec85)
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
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>
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>
This was previously intented to be used in the RunConfig Add... menu,
but this role is now taken by RunConfigurationCreationInfo::displayName.
This fixes also a regression for setups that relied on
QmakeProject::buildTargets() and a fix up empty display names later.
Change-Id: If75fc79efbdedc918a126e50c962fc188d7a3ebc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's not really different from Project::parsingFinished.
Adapt users.
Change-Id: I47d23469df2ec52c5d823508772a7e8b8ad429ce
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>
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>
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>
Do not report success of a qmake parsing run based on every .pro-file
having reported success. Take the top-level .pro-file's success value
instead.
This fixes e.g. Creator, which has some .pro-files that error out in
some conditions.
Task-number: QTCREATORBUG-18992
Change-Id: I888141e723da84fb780ccd84c86acc25d03f5f28
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Let project managers store information whether a project part
belongs to an executable or a library and use this information
inside the AutoTest plugin.
This information will help to determine which targets are
relevant for the execution of tests.
Change-Id: I93b42797bf55225425398dc83aecea3c99eea290
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The old code model expected the macros as C++ formatted text
("#define Foo 42) but newer targets like the Clang codemodel expect key
value arguments like "-DFoo=42". So instead of parsing the text again and
again we use an abstract data description.
Task-number: QTCREATORBUG-17915
Change-Id: I0179fd13c48a581e91ee79bba9d42d501c26f19f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
qmake from Qt4 does not provide C++ standard and
clang can't properly compile Qt4.8.6 and earlier
with c++1z. Behavior in this commit mimics qmake
from Qt5 which also provides c++11 as a default
standard.
Task-number: QTCREATORBUG-16441
Change-Id: I3d29891d6e47f2367f2b3b2bf4be4d86661924e9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Since QNX was split into it's own Abi (QnxOS), it is no longer
piggybacking on the UnixOS Abi. When this change occurred,
there was no change done to collectLibraryData function so on
QNX we were no longer seeing libs created from projects that
were subdirs of a main project.
Related QnxOS change: e69c2eb
Change-Id: Ibb4ff8932ca5d6eea317946aecb53f58ddccc0ea
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
... and use this as a base for all RunConfigurations.
Clean out code in the individual run configurations dealing with their
enabled/disabled state.
Change-Id: Icc2ea136b056f7aea7ce96480b4402459d7ac0ce
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
asyncUpdate is only ever called via scheduleAsyncUpdate, so only
notify about parsing start there.
Change-Id: I4311c6ac1add354de96cc25c0cccd0504409e0a8
Reviewed-by: Tim Jenssen <tim.jenssen@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>
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>
