... 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>
Effectively from container of pairs to pairs of containers.
Saves a few transformations and temporary lists at the price of
effectively storing the keys twice. This is all small stuff, so
it should not matter performance or memory-wise at all, but helps
me to reason about potential complexity on higher levels.
Change-Id: Idf9e235b64d97b1168278ea3dcda34a476c20c08
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... when auto-detecting kits.
Take the entire ABI into account, including binary format and word
width.
Fixes: QTCREATORBUG-31119
Change-Id: I495faf3c54738750bddac65f5a1919144b9fecd4
Reviewed-by: Christian Stenger <christian.stenger@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>
Make the aspects private, but provide accessors to value and
defaultValue as needed. This allows setters to be kept protected
when wanted.
Change-Id: I26f93f62d4ac2e7346f95543c38d8ac9156348c2
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... and IDevice::qmlRunCommand, currently for storage only.
Leave the GUI side as-is for now, as this synchronizes the widget
content with the local copy of the device data to allow the
device tester to be run with the visible data.
Change-Id: Ie8fb967c9a7f8246eec71d52c9b714ca3b3f5acd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The build key is legitimately empty for CustomExecutableRunConfig.
Amends 07df45cdeb.
Change-Id: Iadc992b772913599e5af0d5ea5104188707fad45
Reviewed-by: Christian Kandeler <christian.kandeler@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>
From Store toMap() to toMap(Store).
More symmetric code on the user side and better in line with
ProjectConfiguration/AspectContainer at the price of a few
more lines in the base.
Change-Id: I6069c96c250c1846e870879bcb52c58fdd806478
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes things more deterministic and ensures we consistently prefer
the version-less variant from a set of file paths pointing to the same
compiler executable.
Example on my machine:
/usr/bin/aarch64-linux-gnu-gcc
/usr/bin/aarch64-linux-gnu-gcc-14.1.0
/usr/bin/aarch64-linux-gnu-++ (no versioned variant present!)
Before this patch, QtC preferred /usr/bin/aarch64-linux-gnu-gcc-14.1.0
to /usr/bin/aarch64-linux-gnu-gcc, because it was found first when
iterating the directory, and then discarded /usr/bin/aarch64-linux-gnu-
gcc as a duplicate, which resulted in an ugly asymmetry between the C
and C++ toolchains.
Fixes: QTCREATORBUG-31132
Change-Id: I2da252beda1b565e66906f10fa1e8a9d36ad852c
Reviewed-by: hjk <hjk@qt.io>
This intentionally keeps the lifetime (almost) identical.
Change-Id: Ic420d8c5f89eaad33e38160bb8ee26965830047f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes later reasoning on what can (not) happen in the destructor
easier.
Change-Id: Icec12738e37c95d8d318d0d8fc2bc9b0b60e436d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In expanded items in the session list in Welcome mode.
Adapt the project display too: We showed the base name of the project
file as the project "title", which is "CMakeLists.txt" for all CMake
projects, and also for other projects doesn't really add interesting
information over the file name that we show.
If there are projects in the session, show a title "Projects" and the
list of open project paths.
If there are no projects, but open files, show a title "Files" and the
list of open file paths.
Limit the list of paths to 5 in both cases (adding "..." if there are
more).
Fixes: QTCREATORBUG-7660
Change-Id: I2e250c54f88932aaa95b926f60e0005da9c7a89e
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
So we can add reading the settings just to retrieve a file list in a
second step.
Task-number: QTCREATORBUG-7660
Change-Id: I65856ab97bfe2ee69194d484926f83621fa85327
Reviewed-by: Alessandro Portale <alessandro.portale@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 the arguments contained html-tag like parts (e.g. "<br>") they would disappear from the summmary.
Change-Id: I7e286ef439af2883152a147aad55f2b9bea6e2d3
Reviewed-by: hjk <hjk@qt.io>
It has some platform specific warts, filepath.h is somewhat
cheaper and less ugly overall.
Partially clean up surroundings
Change-Id: Ida1fd470ec020f69c446109427f92a08e879789f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Since this means that StringBuilder expressions are not usable
as arguments anymore, use .withSuffix() more extensively.
This makes this "unusual" construction also a bit better findable.
No measurable performance gain or loss in either direction.
Change-Id: I04508e77764455bd9d3a21eda63bc6de01508e4b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
So people can at least add a custom build step
Change-Id: I78f3601233c776501bdc73fb7d67cbfeb886ced2
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Avoid sharing the workers with the engine creating the
snapshot to avoid closing both when stopping the debugger
engine for the snapshot.
Correctly detach at finish to avoid having a runcontrol
appearing still running.
Fixes: QTCREATORBUG-31220
Change-Id: Iccb54b0fc2d7f5bf54b42a116e56c1a840b1f46e
Reviewed-by: hjk <hjk@qt.io>
Limit code repetition by introducing convenient class template.
Change-Id: I90b45a305c5a6f28bf75a602c14ff055928cda48
Reviewed-by: Christian Stenger <christian.stenger@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>
We in principle support a map of locale->string for keys starting with
"tr" like "trDisplayName". This didn't work everywhere.
We may not cast the value for these keys to QString before passing it to
`localizedString`, since that would result in an empty string if the
value is such a map.
Also fix the documentation since we remove all parts from '_' (to also
get rid of encoding parts).
Fixes: QTCREATORBUG-23575
Change-Id: I2be795053e645c8bf81417d0db69cd7e63eff022
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The enabledChanged() signal is already a member of BaseAspect,
so no need to repeat this signal in subclasses.
Found by Axivion plugin.
Change-Id: Ifc12dc97e134ff1f873df2e5fa5830be55777b81
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was used for qmake and cmake up to Creator 4.11 (Dec 2019).
Projects created or touched afterwards are unharmed.
Projects created before that and not touched since then will lose
runconfigurations.
Change-Id: I745aa3641749462a0420df6f658055a78fd52c8e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Call setSearchRole(...) to create a suitable find aggregate.
Use it in a few places.
Change-Id: Iaa663d13bbc7776019e7b18ea720cc2411e0b691
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
After 83111bb3, the path validity result was coming in later and
was not considered for the page completeness check any more.
Fix that by running the check again when the path result is ready.
Change-Id: I2aab6b2130896d63f7e0359ced39e758393a2644
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
