Rename process.h back to qtcprocess.h
MSVC's "threads" standard header includes <process.h>, and that ends up
including our process.h from Utils.
There already was a hacky workaround in place for a similar issue with
MINGW, but that doesn't work with MSVC because that doesn't have
Simply use a name that doesn't conflict.
Change-Id: I1159cd2096b4f2dbc4a1728d0131dd6edd30ebd3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
It's the "persisted" form of the content of the original aspect's data,
calling it 'aspect' already confused me a few times.
Change-Id: I88a6f76f0ca39d3d36dde9b84287032ceecf7033
Reviewed-by: Christian Kandeler <christian.kandeler@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>
And add a test to document what we expect from devicectl.
Change-Id: Ic69af99a472976a6c06801a646af59f8139d5624
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
And add a test to document what we expect from devicectl.
Change-Id: I2f5312ebadef60239b77308acb7114f1d55143b4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
That uses the various devicectl commands for starting and stopping the
app, and polling it's state for Qt Creator's stop button.
Getting app output and debugging and profiling are not supported, since
devicectl doesn't provide the necessary functionality.
Fixes: QTCREATORBUG-29682
Change-Id: Ied63b280458e5c109446a140a7774c2909aad62f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Unlikely to make a difference in practice, but removes so unwanted
.toString/.exists.
Change-Id: I32c037aa87bb13cecb5b783fe0b36850e163f9c5
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>
In order to conform to the theory: "Removing all
QTC_ASSERTs and QTC_CHECKs should not change anything".
Change-Id: Ieed804e44f4ca78a020444eb3f73d64d1bbdc916
Reviewed-by: hjk <hjk@qt.io>
Removed also some other includes that were marked
with yellow triangles. In some cases includes of
runcontrol.h were substituted with other includes,
like qtcassert.h.
Change-Id: Ica40f68198c7f8f70e6047acb2eddc8ef017e43d
Reviewed-by: Christian Kandeler <christian.kandeler@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>
The data is now pulled out of the runconfig directly instead of relying
on the indirection using the runconfig pointer inside RunControl.
This is only barely better, but gets rid of one direct user of
RunControl::runConfiguration().
Change-Id: If93576ba25ea9f3ddbeae2535217f5c2f361eaf6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's the same as FilePath::lastModified locally, and toFileInfo
doesn't work remotely. So it's overall at least not worse.
Change-Id: Ice8d80dcfd01dc38edc1dce2b53e1b5e6274380f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The main QtcProcess interface is nowadays a CommandLine, with no
explicit references left to QtcProcess::Arguments and related static
helper functions, so it only clutters the QtcProcess class interface
So move these items out of QtcProcess, later potentially to a separate
file pair.
Change-Id: I45c300b656f5b30e2e2717232c855fdd97c2d1d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
And AttachCrashedExternal to AttachToCrashedProcess
And AttachCore to AttachToCore.
Clearer.
Change-Id: I47c2eca5cbdbbc0eb38b9f62b2504c96558ff112
Reviewed-by: David Schulz <david.schulz@qt.io>
Fix the following clang-tidy warning:
Call to virtual method 'IosRunner::stop' during destruction bypasses
virtual dispatch [clang-analyzer-optin.cplusplus.VirtualCall]
Remove the reimplementation of IosRunSupport::stop(), as it was
calling base implementation. Make base IosRunner::stop() a final
method.
Change-Id: I8e57a6dd6a44d2a6f00f5af96a11530f62c92429
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For convenience, and use it in some places.
Change-Id: I8f7cb502b37b2fbf4cf2d17cac9c6299558332dc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We need to pass the path to the device symbols, that Xcode downloaded
for the device's OS version, as the sysroot to the debugger. Otherwise
debugger startup is very slow.
We already tried to do that, but it looks like, depending on the
devices, this path can contain an architecture specific part, e.g.
"iOS DeviceSupport/13.5.1 (17F80) arm64e" instead of just "iOS
DeviceSupport/13.5.1 (17F80)". It can still be just the latter, so we
get the devices architecture information, try the architecture specific
directory first, and fall back to the architecture agnostic name as
before if the former doesn't exist.
Fixes: QTCREATORBUG-21682
Change-Id: I2efdbfda0282f1cf0f8d10bd4e5217a298027fcf
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@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>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
