Basically a.onDevice(b) == b.withNewMappedPath(a), matching the order
of b.withNewPath(a).
Whether the (curretly docker-specific) path mapping is useful /there/, and
whether some of the calls are needed at all is dubious. I added some
FIXME and changed a few cases directly.
Change-Id: I7514736ce922f632f1f737bc496f6783389a42b6
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
- doesn't make sense to translate "%1"
- showPreprocessedFile: "reason" contains full stop, put at the end
- add missing closing >
- remove whitespace at the end of translated string
- added missing quotes and full stops
- Remove some control text from tr
Change-Id: I5537c3d12d038e25e2209af1198129fbf959b43c
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
By copying the ${IDE:ResourcePath}/package-manager to
${buildDir}/.qtc/ the problem with hardcoding paths
to old an Qt Creator version can no longer occur.
This also fixes the issue with remote projects by reffering
to the code residing on the host.
With the above issues fixed, enable "Package manager auto setup"
by default.
Change-Id: Ia49654a3b9059f83886e64d065019b2d55e9299c
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Move the .toString() uses into DeploymentData::addFilesFromDeploymentFile
Change-Id: Ic9ef22da1918ca105c92f0231960dab27b0d80bb
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reported by Coverity.
Looks like it cannot really happen in real life though.
Change-Id: I92e09dbe7dc81e694e5450c598c649c956eb7fcc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Factor out backend into more generic function to easily support new
accessors.
No functional changes.
Change-Id: I715ce2842d2c63574bdf6ada0d0e32fbfd5d08fb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We try to locate the old symbol name in the generated ui header and
rename the symbol in the background.
Task-number: QTCREATORBUG-1179
Change-Id: Iaf68e3922cd728cbc87d0dc97125e34b8bdaa6be
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@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>
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 "Autorun CMake" is only visible in the Tools settings page when
the user clicks on CMake tool.
This is not very visible and it doesn't have to be per CMake version.
Change-Id: I57ded0b2e6a3ecb731bb8bc1495b6b61bc04c8b6
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When trying to jump to a symbol in a qml file the Qml Model may find
the location in a generated .qml file in the build folder.
QtCreator searches in all generated .qrc files to try and find
the source file so it can jump to it instead.
Previously not all auto-generated ".rcc" folders would be found
as only the folders of targets (executables) were searched.
Plugins or Static Libraries were not searched.
With this fix, all projects nodes are searched for the ".rcc" folder
and therefore also finds them for Dynamic / Static libraries and
plugins.
Fixes: QTCREATORBUG-27173
Change-Id: Ic51ac8fbc82c15785cbefd76787942a512ecf3db
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Hopefully less confusion about the direction.
Change-Id: I61727d6c4d19e0dfe46f24ff24f5d90f9835d05c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Neither cmake nor qmake know the full iOS compiler command line, so we
have to construct the target triple for the code model ourselves.
Fixes: QTCREATORBUG-28278
Change-Id: I6cac06f340e9388de5c86509a8df4ac00eef87cd
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@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>
Adapt users; also use dialogParent() instead of mainWindow() were
appropriate.
Change-Id: Ib60b118f05c986a70657446c5b2937074243bb5c
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Previously only HeaderPathType::User was allowed for mappings when the
headers and qml files are joined (the case for Qul), but "Qul QtQuick
include" is of type HeaderPathType::System causing the import not found
error in QTCREATORBUG-26751
Task-number: QTCREATORBUG-26751
Change-Id: Ie40ad32c77bb00ad2c01fd1ae28330669db1e785
Reviewed-by: Piotr Mućko <piotr.mucko@qt.io>
Reviewed-by: Dawid Śliwa <dawid.sliwa@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This is unneeded when followed by waitForFinished().
Change-Id: Ia30161da73ea877ba8973903a391100f29be8410
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Currently if no CMake has been registered and a CMake project has been
openend the user will get the error:
"CMake version is unsupported. Update to version 3.14 (with file-api)
or later."
With this patch the user will get the error:
"The kit needs to define a CMake tool to parse this project."
Change-Id: I555884fff1eac321052998d1ef7970a49b2f44af
Reviewed-by: hjk <hjk@qt.io>
... from Project to BuildSystem.
More direct and less use of Target::activeBuildConfiguration().
Change-Id: I148381d23be0f9ab0750ed1440e1b2b3e25aded0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
From removing the "first build in temporary directory" mechanics.
The method that would previously switch the build directory from
temporary to real now just ensures that the build directory exists and
passes the input build directory through. Name it encordingly and remove
the confusing return value.
Remove condition that now was always true.
Amends 0e613918b6
Change-Id: I8d4cff23b3fcba895bc7338e7277d44efb46e8e7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
If the user cancelled the file system progress bar, the the
m_allFiles will be null and shouldn't be used.
Fixes: QTCREATORBUG-27499
Change-Id: I92c509f1e66d0968f921ec103fd81631eed9ab38
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... by direct use of CMakeConfig::fromFile(). It was only duplicating
checks that are done on the user side already.
Change-Id: Iaf5e89c924c2b0a9080db9fe160970bbf6e33154
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... for the repeated stanza
setParametersAndRequestParse(BuildDirParameters(this), ...)
Change-Id: Ibb6e8346a786bb9d6905de7facb374f750e561d3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... from CMakeBuildConfiguration to CMakeBuildSystem.
Less back-and-forth this way.
Also, prefer plain buildConfiguration() over cmakeBuildConfiguration()
back-pointers.
Change-Id: Ie1341302ecc10e53d71ca68b7b6eb5f46cfdad5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The ProjectExplorer::Task::Error will result in having
m_kitErrorsForProject in targetsettingspanel.cpp which in
TargetItem::updateSubItems() recreates the build settings page.
By reporting the CMake project loading as Task::Warning the above
case is avoided the project build settings page is not
disappearing anymore.
Change-Id: Ib2523e6ea86fe5ad6e4bbee4e101b47cb350a68d
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
