Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@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>
Apparently, there are subtle differences between traversing the nodes
and directly looking at the QmakeProFile children. I'm not quite sure
what they are, so let's go back to the old implementation for now, which
fixes the reported crash.
This partially reverts ccd5955843.
Fixes: QTCREATORBUG-22124
Change-Id: I35a3c20bb09666e8c3af797ebd88761141b7db10
Reviewed-by: Steve Mokris <smokris@softpixel.com>
Reviewed-by: hjk <hjk@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>
... for otherwise identically-named targets.
It happens quite often in larger qmake projects that some applications
in a nested SUBDIRS structure get the same name (e.g. a tool and its
autotest).
It was until now impossible for a user to differentiate between the
corresponding run configurations: In the list of run configs, we just
appended numbers, and in the UI element for manually creating run
configs, the strings were even entirely identical. For a practical
example, open tests.pro in qtbase and count the number of run configs
called "test".
Now we detect such collisions early and append the relative path of the
project file to the display names of the affected run configurations.
For now, this is only done for qmake projects: The problem cannot occur
with qbs, and we don't have any complaints about cmake. The
infrastructure is generic, however.
Fixes: QTCREATORBUG-9563
Change-Id: Ic076df9b5a8bda7c9a1f88df683f33c837eaa197
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>
Centralize gathering the kit, toolchains and qt version.
Change-Id: I6bd586ac7925e2ee556fd119f1dab096cd500e41
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This function is exactly the same as SysrootKitInformation::sysroot(),
except that is returns a boolean. And it's always used like this:
if (SysRootKitInformation::hasSysRoot(k))
sysroot = SysRootKitInformation::SysrootKitInformation::sysroot(k);
Which means that the same code is executed twice in a row.
There is no point in this, so let's just remove it.
Change-Id: I95e4de101d6164ed48558b888e22ed8892fc6d9b
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@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>
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>
