Centralize gathering the kit, toolchains and qt version.
Change-Id: I6bd586ac7925e2ee556fd119f1dab096cd500e41
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
...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>
Also remove the signal CppProjectUpdater::projectInfoUpdated() which is
now unused.
Change-Id: I65afe8f96cd8175edaf8ccb6e5067e4f9cd8d99f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
Keeping the build graphs of all enabled targets in memory does not
scale.
Task-number: QTCREATORBUG-20622
Change-Id: Iab711e7e789db51a5ee13aa9bf3c9fbb2e08aa89
Reviewed-by: hjk <hjk@qt.io>
It's been like that for a long time, but the behavior was inadvertantly
changed in a recent refactoring.
Change-Id: I2f301c995c1f9bb235718e02326c4c64dea91694
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
We do not ship clang-cl anymore which makes it impossible
to run clang with MSVC options.
Secondly we used to we tweak compiler options quite a bit so
why not to switch to CompilerOptionsBuilder totally?
Change-Id: Id323cb554587afaea7d9aa530e947a45a03922d1
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
Setting up the qbs run environment is not free, and the respective code
gets triggered from other plugins much more often than expected.
Task-number: QTCREATORBUG-20175
Change-Id: I6529718d20738140963486caef103d6d17958d50
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
These still assumed we can only multiplex on profiles.
Change-Id: Ice3dfe06c1be732ecae42db75155e930b0554b6f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
After switching to a different build configuration, property changes in
the build config widget would no longer cause project reparsing. Likely
caused by e52ebbf217.
Change-Id: Ifebec74475def49885232ad71d4de01f51568fcb
Reviewed-by: hjk <hjk@qt.io>
While the base function is not virtual the "hiding" re-implementation
effectively appears to do the same. So drop it.
Change-Id: I4ab0e0690b948ce3f590c87262d10622b169450e
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Adding and removing files via the project tree is essentially the same
thing as doing it by editing a project file, except that no reparsing is
necessary.
Task-number: QTCREATORBUG-19292
Change-Id: Idb1bcf0e183f34d4de513f69f974e45ac91afeeb
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Found by clazy.
Change-Id: I9ccca922f6aa8b6a8f1c16c6e62db8dae3c4cc6f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Some recent ProjectExplorer refactorings caused the projects to stay
in the parsing state indefinitely, making it impossible to build or
run anything.
Change-Id: I458a5560cc8d0c7c3183c0f104f00b073039f28e
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Fix crashes due to activeProjectConfigurationChanged signal sending
a nullptr.
Uses the same fix as QTCREATORBUG-18865, but in more places:-)
Task-number: QTCREATORBUG-18866
Change-Id: Ic71af5ed26b2a44339f0c687f3f46bfdf62c2489
Reviewed-by: Tim Jenssen <tim.jenssen@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>
Get rid of Project::buildDirectoryChanged signal as well as
Target::buildDirectoryChanged (and the infrastructure).
Change-Id: Ia749e62eec7e182e558d81115dc2a3d07b72b346
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Add a subscribeSignal method to targets and projects that will make
sure all signals of all project configurations added during the lifetime
of the project/target will get connected (if the type matches).
Use this to connect to some signal in all BuildConfigurations of
a project and get rid of code that keeps connecting to the current
build configuration.
Use Project::buildEnvironmentChanged as an example and convert its
usages.
Change-Id: I689bcebac4b191bf3f8a18765bf18eaac371c5fe
Reviewed-by: Tim Jenssen <tim.jenssen@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>
This function is used in some of the plugin unit tests of
QC.
Change-Id: I8e5f5b734a78a207f139b676aa6616abcc9ce7c0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
