Detect whether cmake supports fileapi or not. This is based on the
version number since cmake upstream does not want to add a flag into
the capabilities output:-/
Change-Id: I036adf65cbd1b171f0f98a7c86230a7ca33fff32
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
We regularly pass around strings or filenames or pairs of strings
or filenames and stringlist etc the in the end will be used
as a kind of "command line", with quite a bit of ad-hoc user
code and QtcProcess::addArg etc to set them up and manipulate them.
Let's have a class for that concept.
Change-Id: I288ab939d853b32c717135a65242c584c2beab50
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Less dependent on used type and actually saves cycles.
Change-Id: I87344172c330198e98c11205a80862b3b30271e4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The internal build target key had changed again. Adapt and use
a more error proof pattern to be hopefully safe if it may
change again.
The wrong build target key led inside the AutoTest plugin to a
wrong comparison of build target of the project parts vs. the
build target of the run configuration which in turn ended up
in always deducing the run configuration for the test runner.
Change-Id: I32df578df85cc0206c2b8fdac00acc3a798f0d73
Reviewed-by: hjk <hjk@qt.io>
A product is a project node from which a target binary is produced, such
as a Product item in qbs or a .pro file in qmake.
Change-Id: I6a0e6bed6c02684cb03b2b18fed6a1b493fa78b2
Reviewed-by: hjk <hjk@qt.io>
If the configuration failure was caused by an incorrect option, you want to
be able to fully use the UI to fix the issue.
Change-Id: I3048b1f6e0b4d88e90433df9a36ca18fa72c03c6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This one is weird: The trailing toString() was practically dead.
Change-Id: I02d24bf655dd32ed5f66e9d99c3cef7e150105dc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a non-mutating .stringAppended, doing the same.
Change-Id: I7adb6cae3415942cc9a80088bd75cda9d577d4a5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
One of the few users of the non-const FileName::clear().
Change-Id: Ic1fa5c5ec24ff41170317bf46ed61543a6bfcb42
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Fixes a regression in d4565be655 that
leads to all desktop Kits being assigned a default desktop Qt version,
even though the installer registered these kits with a specific Qt.
Implementations of KitAspect::setup may not unconditionally override an
existing value, since it is called on the kits restored from the install
settings. This is needed because the installer registers toolchains and
debuggers by referring to them via an ABI ("this kit has a debugger that
can handle this specific ABI"), since the installer doesn't know e.g.
about installed MSVC toolchains itself.
That's why ToolChainKitAspect and DebuggerKitAspect may modify an
existing value in their "setup" method. If this should be moved
somewhere else, e.g. "fix", should be investigated, but in a separate
refactoring.
Change-Id: Ibd99e4da03cd7130c49294f4ac79cd8e346fb1b7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Detected by GCC9.
Looks like inCMakeCache was left out by mistake in df62701801.
Change-Id: I231d0d3e102edb95b657aef42c3f2f2f834514a0
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
For consistency, it's straight forwards access, similar to
currentProject, not much to search and find.
Change-Id: I7ce696bdc24b6a8713d6f11e02443a6f94c605f6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In 73b1a765f3, we did not consider that the order of the code mattered,
so we overwrote user-provided deployment information with guessed
locations.
Fixes: QTCREATORBUG-22184
Change-Id: Ied3a7436829e8b857c32e9364508a33414927c99
Reviewed-by: hjk <hjk@qt.io>
This provides correct deployment information as seen by the build system
when Qt Creator cannot retrieve it directly.
It's most useful for autotools and cmake projects, but can also help
with qmake in certain edge cases.
[ChangeLog] It is no longer necessary to provide a
QtCreatorDeployment.txt file when using CMake projects with remote Linux
devices.
Fixes: QTCREATORBUG-21855
Change-Id: I27e07a45dd1565e489f4b573cc3fff8191c57d9b
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Let's use the same approach we have for CMake projects by using
the same TreeScanner class.
Compilation database does not have a concept of the root directory
so let's show a file dialog and ask for it the first time the project
is loaded. Next times we open it we take this path from settings.
This root path can later be changed from the project tree context menu.
Fixes: QTCREATORBUG-22031
Change-Id: I151aed8d0504b2e8aa14aa774cad25f8c86d5c17
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... of SimpleRunWorkerFactory.
This requires being explicit about the SimpleTargetRunner worker
default, but makes the template re-usable for current users of
RunWorker::registerWorker() which I would like to phase out now,
for less variations in the RunWorkerFactory setup.
Change-Id: I32638437e5bb29f143650f5fde706711ab25accf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
CMakeToolManager instance must be created first to avoid connects
to a nullptr.
Change-Id: If8738a26d58c80ffc9a63193240895f1bc9a87ae
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The functionality of this function overlapped with KitAspect::setup(),
leading to unclear responsibilities and resulting in bugs such as the
one fixed by 776d54e435.
Therefore, we drop the defaultValue() function, merging its
implementation with setup() where applicable.
Change-Id: Iefa9c3df8b76e97ddf9ad388516621f7ea6558d4
Reviewed-by: hjk <hjk@qt.io>
We enable the "Run in terminal" checkbox for all applications that
declare themselves console apps, but that's not necessarily what the
user wants. So let them opt out of this mechanism via a global setting.
[ChangeLog] There now is a global setting for "Run in terminal".
Change-Id: Ieeed72fdd01144d9aec0a7c7d4a12b9e5a94cd1d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
