This makes the using code a bit less dependent on qmake specifics
(qmake related ProjectNode specialization vs qmake-only class)
Change-Id: Ied6ced70694b3ac0665d88ec86c4a66577f3a672
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Make sure that significant changes to the build target information is detected.
Improve operator== to look at all the members. The problem here is that the
runEnvModifier can not meaningfully get compared. So add a uint that is expected
to change whenever the runEnvModifier changes in a significant way.
This makes sure that build target information gets actually updated, which then in
turn enables the updated information to become visible in the UI.
Task-number: QTCREATORBUG-21475
Change-Id: Ifa238f90fc4acba8e29b81959fa40f036b632b3d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We checked the command line from the project manager for "-std=X" and
friends to figure out the language version to use. However, if such a
flag was not provided, we assumed the latest version we support. This
could conflict with the actual version of the compiler and its
predefined macros.
Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the
predefined macros of the toolchain. The MSVC compiler is an exception to
this, as it does not seem to properly set the value - check for
_MSVC_LANG if possible, otherwise simply assume some versions as before.
While at it, add also support for C17/C18 and the upcoming C++2a.
Task-number: QTCREATORBUG-20884
Task-number: QTCREATORBUG-21188
Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
It is the type used by the HeaderPath class, so reflect that in
the name.
I also considered to rename HeaderPath to IncludePath, but
that name is reflected in a lot of users, which would also need
to be adjusted for consistency. That would blow up the patch size
for little value IMHO.
Change-Id: I51421dbd3ab8b2874dc32fc82dc394c9b93ce5e9
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
System include paths are appended after other includes by the compiler. So
we should set them as system includes and not as normal includes. Otherwise
we change the include order. Headers in system include paths are not
cluttering the screen with unwanted warning and by the way improve
performance too.
ProjectPartHeaderPath was a dopperganger of HeaderPath, so we merged them.
Change-Id: I7c394b4098b697de79761499ffcd5913cc02d652
Reviewed-by: Tobias Hunger <tobias.hunger@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>
destDir isn't used after a certain point, no need to update it anymore.
Change-Id: I106ce6a521425811b3fa352724e4bed7ac8d7d48
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
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>
