... in the bundle itself, whenever possible.
It's very annoying to have to add this stanza in all places where
bundling takes place, and it's also easily forgotten, introducing memory
leaks.
This also nicely self-documents the expectations of the calling code as
to whether new toolchains can or cannot be created in the given context
as a side effect of bundling.
Change-Id: I78d2d4cdfc1010568f61f201b0d930b01f79a88b
Reviewed-by: hjk <hjk@qt.io>
Motivation:
a) It was ridiculous that when users wanted to manually
add a new toolchain, they had to do the entire setup twice.
b) It was equally weird that users had to take care to choose
matching toolchains when setting up a kit, or indeed that it was
even possible to mix random toolchains in the first place.
User-visible changes:
- The "C" and "C++" categories in the toolchain settings page have
been merged into a single "C/C++" category.
- When adding a new toolchain, the "C" and "C++" sub-menus are gone.
Instead, the toolchain config widget offers two path choosers if
the respective toolchain type supports C and C++ compilers.
- By default, the C++ compiler file path is derived from the C
compiler file path automatically, so the user usually has
to enter only the former.
- In the kit settings page, the "C" and "C++" toolchain combo boxes
have been replaced by a single "C/C++" combo box, relieving the user
of the responsibility to choose two matching toolchains.
Implementation:
The notion that a Toolchain object corresponds to a single compiler is so
deeply engrained in the code that it cannot realistically be changed in
the short term. We therefore introduce the concept of a "toolchain
bundle" as an additional layer that groups matching C and C++ toolchains
together. This way, most code dealing with toolchains stays unchanged,
and only the presentation layer (i.e. the toolchain and kit settings
pages) needed to be rewritten. Once set up in a bundle, toolchains stay
implicitly linked together so the matching only needs to be done once.
In follow-up patches, we will make use of toolchain bundles in all the
places where kits are auto-created, eliminating the risk of mixing
incompatible toolchains in a kit.
Change-Id: Ie6c5add9963e7c1096268dd77acd624671b2674f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
That's what they were intended for. There appears to be no use case for
them to represent e.g. a nim compiler.
Change-Id: I8070fb837fe411c3e2b6e5a335e642497437896d
Reviewed-by: hjk <hjk@qt.io>
When some code adds or removes a bunch of toolchains at once, that
should be made explicit and also be reflected by the respective signal
emissions.
Fix some leaks and typos along the way.
Change-Id: I4a1f12a2378316c5faf70e85a88adc467f076caf
Reviewed-by: hjk <hjk@qt.io>
This replaces the four classes from the GccToolChainFactories
hierarchy by a single (parametrized) GccToolChainFactory, but
makes the "RealGcc" one responsible for all autodetection.
This is a hack to move closer to a "scan only once" setup, and
temporarily necessary as there is currently one factory creates
one type of toolchain, so we need four factories for the current
four gcc-ish toolchain types.
Change-Id: Icbecb1be6e89cf5efad76baf92ef38ac63be074f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In preparation of running it in another thread.
Change-Id: I2cbac1bd45885416f8ee0dfdc95a4998e87d2f8e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These are functional replacements for
QVariant::fromValue(QVariantMap) (or QVariant::fromValue(Store)) and
QVariant::toMap() (or QVariant::toValue<Store>())
We will have a few code paths in the end that need to explicitly
operarate on both QVariantMap and Store (e.g. actual reading/writing
to keep format compatibility etc), so these can't in the end be
simple to/fromValue(OneType) but need an internal 'if' or such.
Change-Id: I954f3cb24fa8fe123162b72bbd25d891dd19b768
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
... by some out-of-band mechanism, keeping previous functionality.
The driving reason is to get the same fromMap signature as in the
AspectContainer base.
Change-Id: Ife7fbf4d0e0f78d88729021eb5220ec4a8ddb2ec
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Similar approach as done with ProjectConfiguration
Change-Id: Ia5e1d464b7c5c64d7a12ee12c7673ff453f24390
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
... to something similar to AspectContainer::toMap() as
preparation for later aspectification.
Change-Id: Ic60060ad1a7eb1aba58ded01221b016c684db073
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Mostly namespaces, but also centralize access to the factory list
for better debugging.
Change-Id: Ic8b19b8c110dc925e0f7ae27af1da2b9e1ec6086
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... explicitly only for the Desktop device. This was implicitly done in
some cases by assuming 'no device' == 'desktop'. Make that explicit now.
Change-Id: I2ce86702a9b5b795fb4832301a11a8c8b40e77ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Specifies the main purpose more clearly. The remaining ones a "true"
(internal) variants in models and as action data.
Change-Id: I8dd3c846e419f29d88283c2f48268ef6685b19fe
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... by FilePath::isSameExecutable().
The only non-mechanical case is the use inside QmakeBuildSystem::testToolChain
using a build environment instead of the FilePath's device environment.
This make a difference in theory due to the use of PATHEXT in the actual
check, but I believe the case that someone creates a 'qmake.foo' and
a 'qmake.bar', adds .foo and .bar to PATHEXT and then complains that
there's a warning missing about not-matching mkspecs has zero
likelihood in reality (and will break other places in Creator anyway).
Change-Id: Id6a8d1e4dc2eb74ca81610ccb1c4ee94c6f47e12
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
For example: /FIC:/Projects/test/config.h
Change-Id: I18dcda6593effa58ece019ce40bca7860cebfc8c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Checking the validity of a toolchain can involve a call to
a remote device.
We cache the status now to speed up places that repeatedly
check the validity like opening the Toolchain Settings Page
Change-Id: I2b1d8aeba99fb9761d60d4710806bf4b767eaac9
Reviewed-by: hjk <hjk@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When configuring a CMake project on the command line, CMake will
(correctly) find and use the compiler from the current developer
directory, usually somewhere in
/Applications/Xcode.app/Contents/Developer
But Qt Creator auto-detects and sets up the compiler /usr/bin/clang(++)
for desktop kits. This leads to a compiler mismatch between kits and the
imported build, and to new kits registered in Qt Creator for the import.
Since /usr/bin/clang(++) is just a thin wrapper that resolves to the
compiler in the current developer directory, resolve that in Qt Creator
with "xcrun -f <command>" too (caching the result), and include that
when comparing toolchains for importing builds.
Fixes: QTCREATORBUG-27591
Change-Id: I301e2a4e267450b488b49d0c32d4ce89001bb5ec
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Old GCC versions have #define __cplusplus 1
Change-Id: I71286656df8f9925c2e0ccc46d32546037423268
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Most inclusions of idevice.h inside other headers are
required just because of IDevice::Ptr or IDevice::ConstPtr
was used there. Unfortunately, since these "using"
are defined inside a IDevice class, we just can't
forward declare IDevice::Ptr nor IDevice::ConstPtr.
Instead, create a separate header that defines
IDevicePtr and IDeviceConstPtr while having IDevice
forward declared. Redefine IDevice::Ptr/ConstPtr
inside IDevice to use IDevicePtr/IDeviceConstPtr.
Now, instead of forward declaring a IDevice::Ptr
it's sufficient to include the idevicefwd.h.
This drops the number of files being recompiled
after touching idevice.h from ~770 to ~210.
Change-Id: Ib6f2982aa0761fb4cd6593badb9c3c0c527ea535
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
... for the clang code model. Otherwise, it won't work with GCC
compilers for architectures clang does not know about.
Fixes: QTCREATORBUG-26913
Change-Id: I90115f2f562eae9922b90c500630ccf988542ca3
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
It's not unusual for the toolchain auto-detection procedure to encounter
binaries that turn out not to be valid toolchains only after running
them, either because they are genuinely broken or because their names
match a compiler name pattern, but they are not actually compilers.
Until now, we would re-run such executables on every start of Qt
Creator, potentially delaying start-up unnecessarily.
Now we store them in the settings and do not try to run them again.
For now, the collection of bad toolchains is done for GCC only. Follow-
up patches will add support for more toolchain types.
Change-Id: Icfa28de523737bdd88af3a2bfa8b947326c1bc70
Reviewed-by: hjk <hjk@qt.io>
Also, make some functions const and use an alias for QList<ToolChain *>.
Change-Id: I6a1cbcb79bfaa9d252c4b69e00aa93e5d0dabe2f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Would be useful to link auto-detected items to the source of
their detection and later automatic removal when the source vanishes.
This is bit more fine grained than the existing detection() and
mimics what QtVersion, Debugger and CMake have.
Change-Id: I2fae95e7e3c2e8191e9ff4cc7f36dc3fde86cf18
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
At startup the Android plugin looks at the NDK(s) for tool chains, and
the for matching tool chains already registered in Qt Creator. If it
finds one, it doesn't register a new one, but simply force-marks the
found one as auto-detected.
(See AndroidToolChainFactory::autodetectToolChainsFromNdks)
Unfortunately changing the auto-detected property of a tool chain
triggers a full update down the line, which for example Qbs takes as a
hint to re-create profiles.
This simply doesn't make sense. Setting the auto-detection flag
shouldn't result in these updates.
Task-number: QTCREATORBUG-25463
Change-Id: I22a5f6fbe08124a08041bf871e683bdbda279c01
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This reverts commit 6baf09bf91.
sdktool still writes the toolchains with the old settings key.
This should be changed in a follow-up commit, but since we missed
updating the key used in sdktool, we have to stay compatible with that
for a longer while still, or we break lots of existing Qt installations
out there (specifically Boot2Qt, which is the main user of the sdktool
operation).
Fixes: QTCREATORBUG-25647
Change-Id: Ie665c9db5fd5bb808f510c53fd4173b8a318bb7c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
