...for the qmake project manager.
When parsing the project files, remember whether a file was discovered
by the exact or cumulative parse. Only files that were discovered by the
exact parse are considered "active" and thus part of the build
configuration. The others are not offered for selection.
Fixes: QTCREATORBUG-16016
Started-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I7a28b4de15e048975d7f0cd737dd8c11f744315b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The cancel methods were called just before setting up the parameters
for the CppProjectUpdater::update() call, which calls cancel() as its
very first action.
Change-Id: I748cb4daa86bc8245cd906b2dff3c7b2d50795b2
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
This moves most of the QmakeProject::applicationProFiles code
to its only user, the android side, and only uses the new
bool includedInExactParse() const hook on the qmake side.
Change-Id: Ica11127c4895be22cafe56757f4cecafa02583ef
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
By disallowing the use of kits with invalid Qt versions.
This can happen when e.g. a Qt version is registered that was deleted
later. Project parsing then fails anyhow, and on Windows even an assert
triggers in debug mode. Better disallow using the kit and provide
information why.
Fixes: QTCREATORBUG-20825
Change-Id: Id6c084c3880c90e691882396653ce7cc6a531699
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
From the QmakeProject::Parsing enum only the ExactParse was used
via function default parameters and always compared to the
ExactAndCumulativeParse value.
This has been like that since at least 4.4 (proably longer), so
it's fair to assume it's not needed.
Change-Id: I46c227cf1fa6e6aea0b184b49937e7cb129db635
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Add file extensions to execatables about to be deployed based on the
OS found in the toolchain's targetAbi instead of using the hostOs().
This should fix deployment from windows to non-windows machines.
Task-number: QTCREATORBUG-21608
Change-Id: I83678bda1d56ff24848b7b498b95081d00b5a5f0
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
(cherry picked from commit 383f0b9fcc)
Add file extensions to execatables about to be deployed based on the
OS found in the toolchain's targetAbi instead of using the hostOs().
This should fix deployment from windows to non-windows machines.
Task-number: QTCREATORBUG-21608
Change-Id: I83678bda1d56ff24848b7b498b95081d00b5a5f0
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
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>
