... 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>
- Use toolchain bundles, ensuring compatible C/C++ toolchains
- Try harder to match Qt and toolchains
Change-Id: I8739a5e1e75d08df4346d51cb0ee7704ca072489
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@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>
This is effectively the same approach as taken with ProjectConfiguration.
Having the settings separate leads to quite some boilerplate and in the
end to parallel IDevice and DeviceSettings hierarchies.
The unusual registration of the docker aspects are due to the multiple
inheritance, we need to "dynamic" downcast.
Change-Id: I50864e2009f4e525d635decf1c9beaad5e6a5f1f
Reviewed-by: Christian Kandeler <christian.kandeler@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>
It's conceptionally const, and would be useful to use as such, but
the current implementations often modifie mutable state.
To ease the transition pain, rename the previous non-const version to
addToLayoutImpl() and call it after const_cast'ing.
Change-Id: Ic8ca38e40f5df69c3d11121f96ea37648cf4feb7
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
This puts the implementation introduced in acf1ecb47f into use, after
significant simplifications in the class hierarchy. CRTP is not used
anymore, and the new tag based dispatch is also used for Layout::addItem,
effectively reducing the number of different code paths.
The Lua based settings access is disabled for now.
Change-Id: Idb6d1a25675378757c5267bdb630bcd4c1f52d34
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
According to https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews
QSharedPointer impl is poor and it's going to be removed from Qt 7.
Replace QWeakPointer with std::weak_ptr.
Replace QEnableSharedFromThis with std::enable_shared_from_this.
Use std::static_pointer_cast and std::dynamic_pointer_cast
for casts used with QSharedPointer before.
Change-Id: If255a100c790860934f36d52906b93f33c31cfe8
Reviewed-by: hjk <hjk@qt.io>
Editing in the item view was cumbersome and did not generally allow one
variable to refer to another, as there was no defined order on the
assignments.
Therefore, we make the item view read-only and promote the batch editing
widget to be the standard input method. User changes are not sorted
anymore, except in the summary text of the details widget.
Fixes: QTCREATORBUG-28480
Change-Id: I225cf86fff7b001a57d663e1fd267a4645e695c4
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
... when the "Manage" button is clicked.
Make use of this in the device settings page.
Fixes: QTCREATORBUG-25077
Change-Id: I1173a72d4c538c839c3e8df278a698b74bd6fca2
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
The current format is apparently stable since May 2017.
Change-Id: I8be705c87578f0e93dbb9494206ccf3e5d8b9e64
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's mostly used in connection with the debugger, so put it afterwards.
Change-Id: I6351b4c3db34e1b740c444c04205544ea88b8e8a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by direct calls. More direct, and less use of QObject-ness of
the KitAspectFactories.
Change-Id: I7487875d95752b681475248ca0e5494d640e064e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
