For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The QmakeKitAspect's purpose is to let the user force a specific mkspec
when building with qmake. It is unexpected that it silently changes the
kit's toolchains.
The code that automatically sets up a Qt version for a given toolchain
already exists in QtKitAspect and appears to work just fine these days.
Fixes: QTCREATORBUG-23191
Change-Id: I2727a4faa2285738d0e81e8558ca02e97ef319d3
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>
... and BaseQtVersion, and QmakeBuildConfiguration.
Change-Id: Iac5f768b80a7f8c2ea9a37d099b285d5793270db
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Even if this is part of a directory name it is naturally closer to a
"string" id than a file path.
Change-Id: If66f930526744379ce86e2b18bd9eac7fabfe773
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If the user explicitly sets the mkspec for a kit, we should remember
that, even if it happens to be the (current) default mkspec of the kit.
Fixes: QTCREATORBUG-16205
Change-Id: I9ee047bdaecce1aae7d0a8e4dfc2a0a25b6be744
Reviewed-by: hjk <hjk@qt.io>
The functionality of this function overlapped with KitAspect::setup(),
leading to unclear responsibilities and resulting in bugs such as the
one fixed by 776d54e435.
Therefore, we drop the defaultValue() function, merging its
implementation with setup() where applicable.
Change-Id: Iefa9c3df8b76e97ddf9ad388516621f7ea6558d4
Reviewed-by: hjk <hjk@qt.io>
The authoritative source of information about a KitAspect is the
KitAspect itself, not the associated widget.
Change-Id: I72d3d0425b845457846a940350bab59f1ff0cc2c
Reviewed-by: hjk <hjk@qt.io>
A KitAspectWidget class is tightly coupled with the respective
KitAspect, and no one else ever needs to see any KitAspectWidget
subclass at build time.
Change-Id: I1883af3b054c225e1ff5dd913118715bfdbaacfc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
In the situation where a cross-compilation tool chain has the same ABI
as the host.
Prefer toolchains and debuggers in PATH if the ABI matches. This is just
a short-term hack. It is not fail-safe, because either both tool chains
could be found somewhere in the PATH, or the "right" desktop tool chain
could not be in PATH, but manually added.
Anyhow, in many default setups this should improve the result. (In case
of failure the user can still change the kit manually.)
A better long term solution would be to make our ABI settings more
flexible.
Change-Id: I6ec5aaf45ef0b983cd949895dacdd5190f786219
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
All the KitInformation methods need to gracefully handle a kit that is
a nullptr. Ensure this is indeed the case.
This might fix the actual trigger for QTCREATORBUG-19469.
Change-Id: Id78ac8a26c1be908f41a425ff1935b86888e4b8b
Reviewed-by: hjk <hjk@qt.io>
This re-uses what work in RemoteLinux. There's still a compile-time header
dependency due to the QmakeProjectManager::Constants::KIT_INFORMATION_ID
constant.
Change-Id: I6d6b8bbaed8ec2e80d54afe62a5a6b7f84eb37ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, add context to connect() expressions where we are or were
capturing "this".
Change-Id: I6e006ba6f83d532478018550d148ee93eca59605
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The auto-detected Kit used by default in creator used to set up a
set of toolchains, that usually match up with each other (this relies
on the auto-detecion of toolchains to detect groups of compilers
in one go).
Then the Qt version selected (or better: The mkspec) will change the
C++ compiler if necessary.
Change this to actually pick a good C++ compiler and also update all
other toolchains to match the C++ compiler.
Task-number: QTCREATORBUG-18571
Change-Id: I95ddd9b83cf1642fba648919b76d3e3b7aa24c43
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Original check was introduced in
200e7dd437, but in Boot2Qt 5.9 Qt versions
use a different id.
This lead to Emulator kits using system g++ on Linux instead of the
provided one. Possibly also other way (desktop using emulator g++).
Task-number: QTCREATORBUG-18169
Change-Id: I42f0da784ccaf749ce2eaba5d689bbdb8c11f971
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Allow to provide a Predicate to ToolChainManager::toolChains and
add a ToolChainManager::toolChain method.
Change-Id: I0849f6fa67ffd8d5c6cfe4253cb0a326e1b023fa
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
HACK! The magic in QmakeKitInformation::setup() should be removed altogether,
but that is something I dare not do in a patch release. HACK!
Change-Id: If3f0ec9976171977c253cee531203ac3ab41c6a7
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not consider non C++ toolchains when searching for a matching toolchain.
Change-Id: I2b06fd677ec3b89d0c15290ba170344629ded20e
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
