We use a value of 200, which is also GCC's default.
Fixes: QTCREATORBUG-28770
Change-Id: Id02b324cd2ffa81a709441a5d93856bcd06501c3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It adds an indirect dipendency to QmlCompilerPrivate too. We stick to Qt
6.5 because the private API changed.
Task-number: QDS-9049
Change-Id: Icb0b406fc47759763384e167c0cabbffc1c9e186
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Children inside the object inspector are sorted
lexicographically nowadays.
Change-Id: I2f704e3a3cca526246babb2b12d48fe359eb6e6b
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Amends a3153c535d
QT_QMAKE_EXECUTABLE was not taken into consideration and this would
result in not matching kits.
Also Visual Studio generator will not have a CMAKE_C|XX_COMPILER values
in the cache.
On Windows there could be paths with "C:" vs "c:" and the hashes again
wouldn't match.
Change-Id: I5da5fafbd29f3d1fd8c9615c41b7659e63c30ff1
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Depending on the presence of the llvm that had been used when building
QC we need to expect its clang.
Use special environment variable to be able to do this correctly.
Change-Id: I2497bbd96483f37aa90842d7fffa5d0a8103ff45
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Variant 2:
Inside this test the process 2 should finish first, then synchonously:
- process 3 should exit setup with error
- process 1 should be stopped as a consequence of error inside the group
- processes 4 and 5 should be skipped
Variant 3:
This test ensures process 1 doesn't invoke its done handler,
being ready while sleeping in process 2 done handler.
Inside this test the process 2 should finish first, then synchonously:
- process 3 should exit setup with error
- process 1 should be stopped as a consequence of error inside the group
- process 4 should be skipped
- the first child group of root should finish with error
- process 5 should be started (because of root's continueOnError policy)
Change-Id: Ie34737244c7da4334a6cbbae4f0ddba99503d09c
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It's used anyway, relies on the expected project
tree and works around a problem on some machines.
Change-Id: Ic1e3e7a3f492f37d70c4409699ca78ad548d7445
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Get rid of std::bind.
Enclose each data tag of processTree inside its own block,
so that "root" and "log" names are unique within each block.
This makes each block look like a pattern with filled data up.
Introduce TestData structure, so that it's harder now to mix
the order of test data in new rows.
Introduce some enums instead of bools to make more meaning
on the returned data.
Change-Id: Iffe49cf1c7f912378467ab9f9c1256003dba7b9c
Reviewed-by: hjk <hjk@qt.io>
For unknown reasons this does no more work on a couple of machines.
Re-doing the original approach by explicitly expanding the tree as
necessary up to the file we want to open.
Change-Id: I329e18f3e2162e381e11fb6164a448ae67def606
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There is now a mid size image in the image cache. It's logical size is
150x150, so it is 300x300 for HighDPI.
Task-number: QDS-8918
Change-Id: I6586b2e82b9e74737f46b67c441201ad4964fca0
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
So far we expected that both images are null or not null. But sometimes
you only want to save one image type in the collector. This will try to
generate the image cache entry again if you try to get a null image so
be careful.
Task-number: QDS-8917
Change-Id: I765f5b82589f52e439513a11926314ad2d99a928
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Don't define 2 separate group setup items. Make OnGroupSetup
be able to handle also dynamic setup - like it's done with
CustomTask's setup handler.
Change-Id: I43e135f268ea96419b44ef5a4325707a124b4921
Reviewed-by: hjk <hjk@qt.io>
Use TaskAction for dynamic group setup. Get rid of possibility
of selecting group's children to be started inside group setup.
Use dynamic children's setup instead, so that each individual child
may decide itself whether it wants to be started or not.
Change-Id: Ie31f707791db0dc26be92663ca6238b8e49c3b98
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Originally the idea was to only expose LayoutBuilder, but we
are getting more and more related items. Be consequent now,
and have everything in Utils::Layouting, but not in nested classes.
Change-Id: Ic0f98595882e5c60a25c30ec52df4a0ea79bc0ca
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Before it was possible to dynamically setup groups only.
This functionalily is probably good enough to replace
Group's DynamicSetup, as it seems much more convenient.
Change-Id: I56080f0ffa844847ca955cf52ccb07f3b4e4c731
Reviewed-by: hjk <hjk@qt.io>
... and re-use the old QtcProcess::readAllStandard* names for
a QString-returning 'decoded' version.
For now, only use that in 'full Utf8' cases, to stay bug-compatible,
the plan is, however, to employ the QTextCodecs we have already
in the channel buffers. That will be one-by-one, though.
Change-Id: Id209e0671920d4ea4197918e872f441254112d52
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When parsing remote .pro files the parsers needs to pretend it runs
on the remote device.
All internal data are now "local on the remote", so that string
manipulation in .pro files "just works", and a 'device root'
string is passed around to relevant functions which then use
it to construct FilePath::toFSPathString()-style paths that
our custom FSEngineImpl can then map to the real device.
Remote $$system() calls are intercepted by the local parser and
redirected using the usual QtcProcess mechanims.
Quite a bit of the ProParser needed adjustments, so there's some
potential for regression.
Task-number: QTCREATORBUG-28242
Task-number: QTCREATORBUG-28161
Task-number: QTCREATORBUG-28355
Change-Id: I6100e7aca4e1db35f5e9689004110aab57e2c595
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The parallel limit constrains the number of parallel tasks
run in the same time. So, if e.g. a group contains 10 children
and the parallel limit is 6, only first 6 tasks are being started
on the beginning and the rest 4 are being postponed until some
running tasks are finished. So, when the one of 6 running tasks
finishes the group starts the 7th task and so on.
Setting parallel limit to 1 means sequential invocation in fact.
The value of 0 means there is no limit and all tasks are run at once.
Remove the ExecuteMode enum, as this is modelled now by the
parallelLimit.
Change-Id: Ice59318be0915401f05bb5a5804078bdc591d09f
Reviewed-by: hjk <hjk@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>
The original text before the SPDX change did not include a potential
GPL-4.0, but GPL-2.0.
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 LGPL-3.0/LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only/g" {} ;
Change-Id: Id5e40d3e174ecea660a09e88a02bd57505f1875d
Reviewed-by: Lucie Gerard <lucie.gerard@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Since we do not support Qt < 5.15 anymore, and as a first step
for getting rid of our special FindQt5.cmake.
Change-Id: Icc5dbaf9b0a3a622b1f609ff114b9decb6d2856c
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
