There are some internal hard asserts on that.
Change-Id: I93bbdff0c9625d42d5f9da3f12219ad90c478d5d
Reviewed-by: Christian Stenger <christian.stenger@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>
- 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>
... before and after a build.
The previous algorithm did not guarantee the same order, leading to
failure when analyzing an unbuilt project with clang-tidy/clazy.
Change-Id: I8a700408ca0c23b1b14b47ebfe334a41c52afa5b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
QStringRef is gone.
qsizetype vs int.
QMultiHash::insertMulti is gone.
QXmlStreamWriter writes UTF-8 by default.
Task-number: QTCREATORBUG-24098
Change-Id: Id217e40a1f17993a84fc725976e9cb84618b0580
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>
- qsizetype vs int
- QJsonValue vs QJsonValueRef
- #include for metatype system
Task-number: QTCREATORBUG-24098
Change-Id: I066d9e3d5c35766b8aa3adc1c5835b23feb20b37
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
More a buildsystem than a node thing in general and removes
one use of activeBuildSystem and one use of the ProFileNode
-> ProFile back pointers.
Change-Id: Ie007fcd0db9e9294a08b3a1cd68f825c7d3dc9b8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This will help collecting feedback from users affected by bugs.
Task-number: QTCREATORBUG-22508
Change-Id: Idfc22245587dd2d71b229b4ab6c7562fb7a5ecfc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead, we keep the IDocuments as "extra project files" in the Project
class, like the other project managers do it.
This has two advantages:
- The document is no longer created in a parser thread
callback, improving Qt Creator responsiveness while
loading a project.
- The IDocuments no longer get needlessly destroyed
and re-created on a re-parse.
This is relevant because adding these objects to the DocumentManager
results in the creation of file watchers, which is expensive.
Task-number: QTCREATORBUG-18533
Change-Id: I49c03377974e6b33340234dbabbbd82b8d0c827c
Reviewed-by: hjk <hjk@qt.io>
When parsing larger qmake project, the callbacks from the parser threads
are currently overloading the UI thread, often rendering the application
non-responsive until the project is completely loaded.
This patch moves some expensive operations from the UI thread into the
parser threads, at the cost of a somewhat ugly two-stage setup for some
types of objects.
On my Linux machine, I measured that the time spent in parser callback code
went down by almost 50% when loading the Qt Creator super project.
Task-number: QTCREATORBUG-18533
Change-Id: If9624da5b07e81a50c180693580b20a70e1aaea7
Reviewed-by: hjk <hjk@qt.io>
E.g. for Qnx, QT_INSTALL_PREFIX is not a prefix of QT_INSTALL_EXAMPLES.
Fixes: QTCREATORBUG-22592
Change-Id: I3092cd76af01519783e1162ab8e79caaf0836f00
Reviewed-by: hjk <hjk@qt.io>
Effectively the same approach as for Android, but a bit more ugly
as we don't have necessarily access to the appman plugin headers
even at compile time.
Change-Id: I6d00e69b593470e059a16a1fcf6b57bdd550ae40
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was implemented rather sloppily: The file was removed from all
variables, but only added to one. Also, no care was taken to insert the
new file name into the same block the old one was removed from.
Fixes: QTCREATORBUG-19257
Change-Id: Ib309389ba7647189112d5c7dd7b3e784f921d2c3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We show all source files in the project tree, including those which are
listed in scopes that evaluate to false in the current configuration.
This is intended, as we want users to be able to navigate to all files,
not just the ones that are part of the build for the current target.
However, it'd be nice for users to be able to tell which files are
"active" and which ones are not. Therefore, we now mark the non-active
ones as "disabled" in the project tree, just like the QbsProjectManager
does.
Task-number: QTCREATORBUG-22855
Change-Id: Icfb48d4f6a247de76fc109acb84b34f03866e754
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As opposed to qmake itself, Qt Creator tries to resolve the value of
INCLUDEPATH against the sysroot. Therefore we should not reject Unix-
type absolute paths as candidates for sysrootification on Windows hosts.
Fixes: QTCREATORBUG-21164
Change-Id: If4be103061ad3edc64f8d1f5cfeb7c6b48e961c8
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
...without the user having to add them to DISTFILES or OTHER_FILES in
addition to TRANSLATIONS.
Task-number: QTCREATORBUG-7453
Change-Id: Ic9621e66079a52f22272c945b92d183eec852f68
Reviewed-by: hjk <hjk@qt.io>
... when adding and removing files via the project tree.
Fixes: QTCREATORBUG-2196
Change-Id: Ie4ee3a244c9089953cf414d9777fc65b6a8b9689
Reviewed-by: David Schulz <david.schulz@qt.io>
... from a project which are pulled in via wildcards.
Such files cannot be removed from a project file, because they are
not listed verbatim. This kind of failure should not be reported to the
user if the file is also deleted, as the file list will have the correct
state after the next reparse.
Fixes: QTCREATORBUG-22586
Done-with: Christian Kandeler <christian.kandeler@qt.io>
Change-Id: I3dc66fe9a6594be7d0b86f46d830cd099ee49fd7
Reviewed-by: hjk <hjk@qt.io>
