This prodecure requires no further information from the specific project
managers, so we can start it from the ProjectExplorer itself.
Also wait until after project parsing has officially finished and the
run configurations have updated their "enabled" state. Otherwise,
RunConfiguration::isEnabled() will always return false, potentially
leading to the active run configuration getting switched
unintentionally.
Fixes: QTCREATORBUG-21692
Change-Id: I32f4f758b5baa6222329d07b811993568eff1ee3
Reviewed-by: hjk <hjk@qt.io>
... from the environment.
Fixes: QTCREATORBUG-17985
Change-Id: I9b54e550121cfcc0684a6e173337d59d235c6107
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
... to the bits that are actually used.
Change-Id: I39a6ed1f4136d75b776bb89eec6165479097a4ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... from a project which are pulled in via wildcards.
Such files cannot be removed from a project file, because they are
not listed verbatim. This kind of failure should not be reported to the
user if the file is also deleted, as the file list will have the correct
state after the next reparse.
Fixes: QTCREATORBUG-22586
Done-with: Christian Kandeler <christian.kandeler@qt.io>
Change-Id: I3dc66fe9a6594be7d0b86f46d830cd099ee49fd7
Reviewed-by: hjk <hjk@qt.io>
This lets users build the executable corresponding to the currently
active run configuration. It's functionally equivalent to locating the
corresponding node in the project tree and choosing "Build" from the
context menu.
Fixes: QTCREATORBUG-22403
Change-Id: Ic2b729c7ce17f1ad944dc06746bb9d6db90b6c61
Reviewed-by: hjk <hjk@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... when setting up the code model for Darwin targets.
Fixes: QTCREATORBUG-22355
Change-Id: I5cade8d3139dc3602298e9d4d056c9745b208489
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
This provides correct deployment information as seen by the build system
when Qt Creator cannot retrieve it directly.
It's most useful for autotools and cmake projects, but can also help
with qmake in certain edge cases.
[ChangeLog] It is no longer necessary to provide a
QtCreatorDeployment.txt file when using CMake projects with remote Linux
devices.
Fixes: QTCREATORBUG-21855
Change-Id: I27e07a45dd1565e489f4b573cc3fff8191c57d9b
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This happened for all projects with a Qt dependency, because the module
provider kept recreating the Qt modules, which in turn caused Qt Creator
to re-parse the project.
Change-Id: I77c5c8723c1d0bcd477db648692ddaf9e060ce99
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
DefaultDeployConfigurationFactory used extra effort to not apply to the
Qbs (Desktop) case, with QbsDeployConfigurationFactory plugging exactly
that hole with essentially the same functionality, which is even the
default of the base class.
The only differences are the display name, which is dropped in this
patch, and the different keys in the .user file, which are updated
with this patch. Note that the display name "Qbs Install" for the
DeployConfiguration stays with this patch whereas a freshly created
one will get the default "Deploy Configuration" name.
Change-Id: I255371d0a0688fbc6303083eb6aa20563e876264
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
