Most information is available via Q(Core|Gui)Application.
Add an AppInfo structure for the things that are not.
This avoids that the information ends up duplicated and
hardcoded in the plugins, which is not needed or desired.
Change-Id: I4d565e75c42a7b8facafa90c27096ea49359215d
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Introduce and make use of Utils::insert() for QSet with a return value
that indicates whether insertion actually happened.
Change-Id: I655e4bc3553b74fea5ae8956205e4d8070118d63
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It is not uncommon for projects to use quoted file names, which would
break the new file operation support for CMakeLists.txt files.
Change-Id: I8dc5d6843f1723c5709cef28cf3bf89a5c87ec2a
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This brings the lexer back to vanilla CMake version.
The comment arguments were not needed in the implementation of
source file addition / rename / removal operations.
Change-Id: If28b738b9ce93511b109fe09dcd03f42ee07a431
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Amends d8be2491a5
The change above introduced FileApiReader::takeCMakeFileInfos and uses
it to move the information about additional CMake files out of the
FileApiReader. But that now emptied variable was later used to inform
the project about these additional files. So, that broke the automatic
running of CMake when project files (except the toplevel one) changes.
Instead use the list of additional files that now lives in the
CMakeBuildSystem for that purpose.
Change-Id: I1062593029880af9d4c70e72e1bd101d40ad0c00
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
qt_add_qml_module was not consided when looking for existing project
files.
This would fail when qt_add_executable and qt_add_qml_module were used
with the same target name.
Change-Id: Ib7374a3e1213c23aaf12d100a8817a46d57a4303
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
This way the functionality would work even if autorun CMake is disabled.
Change-Id: I54ab47d72664cb42486b260b895f58d37a885cce
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Lookup any variables found in the target definition function in order to
find the source files.
This works for something like this:
set(SOURCE_FILES myfile.cpp)
add_executable(myexe ${SOURCE_FILES})
Change-Id: I8a47ea64b4efa467074f03ed5e1d1d05b2b1bf00
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Removal of a project file is done as a rename with an empty filename.
Fixes: QTCREATORBUG-25922
Change-Id: I4443d4a31723eb1ac93f02bad633bcfaf99a9573
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
This includes both with source files explicitly specified or
resulted from a file(GLOB|GLOB_RECOURSE) call.
Fixes: QTCREATORBUG-27538
Change-Id: I5ee113af168bdb8cd0a96e8ab2ae603c0607fb0b
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
This will add the new added source files (.cpp, .h, .qrc, .ui) to the
corresponding CMake source file as last arguments for known CMake
functions like add_executable, add_library as well for the Qt
counterprarts qt_add_executable or qt_add_library.
For custom functions the code will insert a target_sources() call.
Subsequent calls will add the files to the last target_sources.
The previous copy to clipboard mechanism and settings have been removed.
Fixes: QTCREATORBUG-26006
Fixes: QTCREATORBUG-27213
Fixes: QTCREATORBUG-28493
Fixes: QTCREATORBUG-29006
Change-Id: Ia6e075e4e5718e4106c1236673d469139611a677
Reviewed-by: hjk <hjk@qt.io>
This was the case previously when the path was tied to the Qt Creator
version.
This fixes the docker case when the expanded value gets replaced with
the unexpanded value from the initial configuration.
Change-Id: If005d410bc4408403fd79fa619c58217a499d3a5
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
The BuildDirectory is now assumed to be on the build device.
The default build directory template path is resolved against the
project path mapped to the build directory.
Change-Id: Ie1d147d135e9e551f2ac46cbec583374d524d2d7
Reviewed-by: David Schulz <david.schulz@qt.io>
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>
