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>
When configuring a CMake project on the command line, CMake will
(correctly) find and use the compiler from the current developer
directory, usually somewhere in
/Applications/Xcode.app/Contents/Developer
But Qt Creator auto-detects and sets up the compiler /usr/bin/clang(++)
for desktop kits. This leads to a compiler mismatch between kits and the
imported build, and to new kits registered in Qt Creator for the import.
Since /usr/bin/clang(++) is just a thin wrapper that resolves to the
compiler in the current developer directory, resolve that in Qt Creator
with "xcrun -f <command>" too (caching the result), and include that
when comparing toolchains for importing builds.
Fixes: QTCREATORBUG-27591
Change-Id: I301e2a4e267450b488b49d0c32d4ce89001bb5ec
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The patch breaks several plugin unit tests; at the very least QtSupport,
AutoTest and ClangCodeModel.
This reverts commit 72aa77ced7.
Change-Id: Iaa7f452d0f43d0072b0bbcf8934fa0dcd6f9b240
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
qmake is a "build tool", and it is also a "query tool" when called with
parameter "-query". Qt Creator, so far, assumes that building and
querying with a Qt installation are done with one and the same tool:
qmake. This change adds the ability to register a Qt version vie either
qmake or qtpaths and still build with qmake, if that is installed (which
is not anymore mandatory from Qt 6 on).
1) Distinguish between Qt query tool and qmake build tool:
Add QtVersion::queryToolFilePath() to the existing
QtVersion::qmakeFilePath(), and use queryToolFilePath in most "query"
related code, and qmakeFilePath when building with qmake (e.g. in
QmakeProjectManager).
Also, a couple of functions and variables were renamed from *qmake* to
*queryTool* in order to express that the affected code is about
querying/managing Qt versions rather than about building with qmake.
2) Support manual Qt Version adding by qtpaths via file dialog
This change adds qtpaths to the "Add" Qt Version file picker filter.
After selection, "qtpaths -query" is executed for testing purposes. If
that fails, (e.g. because it is an older Qt version), qmake is instead
chosen, silently.
Task-number: QTCREATORBUG-22175
Task-number: QTCREATORBUG-25546
Change-Id: I4d9c1e7eec7d5ae7c5a8d2e1a1ed95addff69966
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qmake may construct QMAKE_CC and QMAKE_CXX by using paths from
environment variables that have native delimiters. That is the case with
Android (see mkspecs/android-clang/qmake.conf).
That leads to QMAKE_CC and QMAKE_CXX having mixed-style path separators,
and that is the reason to treat them as user input.
Change-Id: I1baf180c16710f4cd00ac182fa241b84ae99fa38
Reviewed-by: David Schulz <david.schulz@qt.io>
The main thread doesn't kill processes directly, but
sets just the cancel flag.
Instead of waiting infinitely long for a process to finish
we poll periodically (every 100ms) for the canceled flag
inside the thread that started the process.
Amends: a30aa4421a
Task-number: QTCREATORBUG-26333
Change-Id: I599d5c6cd69381cadc4a01c65f6a79f9a9bbd3fb
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There was no proper separation of responsibilities between these
plugins. In particular, CppTools had lots of editor-related
functionality, so it's not clear why it was separated out in the first
place.
In fact, for a lot of code, it seemed quite arbitrary where it was put
(just one example: switchHeaderSource() was in CppTools, wheras
switchDeclarationDefinition() was in CppEditor).
Merging the plugins will enable us to get rid of various convoluted
pseudo-abstractions that were only introduced to keep up the artificial
separation.
Change-Id: Iafc3bce625b4794f6d4aa03df6cddc7f2d26716a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
E.g. when the last use of the libraries was removed from .pro files.
This also makes the use more similar to the other build systems and
allows making Project::{add,remove}ProjectLanguage private.
Change-Id: Ib23d83f2fb5aab728b344c164a1331429b44e345
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
also renamed the qmlscene* qmlRuntime*
Change-Id: Ifd522e21f5ce30aaa54060fdcebee2cd8b9463c4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Do not try to reuse the QFutureInterface that is used for the parsing
process. Reusing the QFutureInterface can lead to issues. So far no
problems were triggered, but a30aa4421a
introduced a watcher that tells the qmake parser to ignore all system
calls after the future was canceled. This was somehow, sometimes
triggered on the reused QFutureInterface even though the user didn't
cancel anyhing, leading to all system calls to bail out in the
subsequent run.
Using a new QFutureInterface instance for each parsing run solves the
issue.
Amends a30aa4421a
Fixes: QTCREATORBUG-25970
Change-Id: I6836c97038c36968e93815c6121bc284edbe19bb
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Each call of CppModelManager::updateSourceFiles detaches the current
snapshot.
The extra compilers where set up and triggered individually, and
resulted in individual updateSourceFiles calls with the single result
file of the extra compiler. For Qt Creator this would lead to 200
calls in quick succession after project load, potentially leading to a
freeze of multiple seconds.
Instead of updating the result files of the extra compilers individually
after project load, integrate the update into the regular project source
file update. So we end up with only a single call of updateSourceFiles.
For this the project updater needs to trigger the extra compilers, and
wait for all to finish as well as the regular project part update,
before
triggering the parser.
Task-number: QTCREATORBUG-25783
Change-Id: I34f6df0fc0f96bcb42ee65019bee39cf49176c1f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and isSubProject.
Take the opportunity to rename them into isInQtSourceDirectory and
a isQtSubProject to make its limited scope clearer.
An open question is why this is only used for qmake projects.
Change-Id: If36f9457583eac17e149624ec46e5de10dd4a5a5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There are some internal hard asserts on that.
Change-Id: I93bbdff0c9625d42d5f9da3f12219ad90c478d5d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... while a parse is going on.
Fixes: QTCREATORBUG-25137
Change-Id: I02a914332ef120caee044139581e1901b4537bff
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Take care of handling file permission changes centrally.
TextDocument had its own, caching implementation of tracking the backing
file's read-only state. Move that into IDocument directly.
IDocument::reload with a permission-only change is not a very
interesting case, but every subclass needed to add handling of it.
Instead, remove TypePermission from the file-change types, and handle it
separately via the now unified checkPermissions() implementation.
IDocument::reloadBehavior already was never called with TypePermission.
Change-Id: I321d47ba6193bc878efa9bb50ba7a739fa492745
Reviewed-by: David Schulz <david.schulz@qt.io>
That is, processes run via qmake's system() function.
Fun fact disovered while implementing this: "Canceling" the loading of a
qmake project did nothing at all except making the progress bar red at
the end of the parsing procedure. Now at least we terminate the
currently running processes invoked by system(), so the parsing threads
can continue and eventually finish.
Task-number: QTCREATORBUG-24825
Task-number: QTCREATORBUG-25000
Task-number: QTCREATORBUG-25194
Change-Id: Ic92ef200d3a49bbdeff0429ae7038fe3f1935b38
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
- message(): Print to general messages and blink
- warning(), error(): create item in Issues pane
- parse error and other errors: create item in Issues pane
Task-number: QTCREATORBUG-24430
Change-Id: I6b37cef0b9e53e2207341bd179e2c60a40da9ee0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has too many side effects.
Amends fcd6384f4d.
T_SYSTEM and E_SYSTEM are now treated the same.
Fixes: QTCREATORBUG-24551
Change-Id: Ib6df2762d329f2ddc0dd66190454159d446a9ac9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
After a re-parse, the existing IDocuments need to be updated with the
new QmakePriFile object, as the old one may no longer be valid and thus
cause a crash on the next re-parse.
Amends f3bd07efd1.
Fixes: QTCREATORBUG-24683
Change-Id: Ib03d3005cb7831f1e05cb116aa3cdfe6cf5e72ad
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was broken in commit 37aecdd112, where we overlooked that a special
type of IDocument was used that triggers a re-parse of only the affected
part of the project tree. As a result, all changes to a .pri or .pro file
would trigger a re-parse of the entire project.
Fixes: QTCREATORBUG-24572
Change-Id: I480cff4e53cf86a17e1eaac0eb9b32901bc87051
Reviewed-by: hjk <hjk@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>
The ClangTools and the AutoTest plugins use an internal
mechanism to load and configure a project when performing
their integrated unit tests.
Both assumed to have exactly one kit present for these
tests.
Make it possible to have more kits present when starting
with existing settings or if more kits get automatically
generated when starting with clean settings.
Change-Id: If2bc66320c4854f1d34a19d17107e8f0b7d64d39
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Prefer source files from contexts where we know that they actually get
built and thus should have includes and compiler flags properly set up.
Also fix the qmake and qbs project managers to not mislabel any non-
application products as libraries.
Fixes: QTCREATORBUG-23394
Change-Id: I0d122c7b58e12d14d68a1ca7337df83074299cd7
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Hide the parameters behind yet another macro to get a uniform layout
and avoid parameter evaluation in the normal non-traced case.
Change-Id: Iaf24b0f1b285c8f664f8b3476ae82c39c1a2d7dd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The problem could be reproduced as follows:
- open any bigger qmake based project (e.g. QtCreator)
- de-activate all kits
- activate one kit
- wait until the first parse (e.g. Debug build finished)
- switch to Profile, and toggle the Shadow build button
The toggling re-starts the parsing. The parse guard will not be released
in decrementPendingEvaluateFutures() (arguably correct as the parsing as
a whole is not done). On enteringing incrementPendingEvaluateFuture()
due to the re-start, the guard still guards the parse, but a new guard
is created in guardParsingRun(). As this happens while the build system
isParsing() is true, the created parse guard will be "non-guarding".
On assigning to m_guard, the original guard object will fire and then
be replaced by the non-guarding guard, that never fires again, so the
the build system will never have hasParsingData(), which is a
condition for the run buttons to activate.
As a workaround for people running into this issue in 4.12.0:
Select 'Run qmake' from the menu (any subproject suffices), and let
it finish.
Change-Id: If7a55db56ec67bac2635fb9a745b9aaf6ca6a413
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
