... 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>
Provide general infrastrucure and implementation for qmake.
Fixes: QTCREATORBUG-16067
Change-Id: I8c6368fe2724c9450dcbc3410b6ca459bbbdc043
Reviewed-by: hjk <hjk@qt.io>
We do not introduce another category, but list them under "Headers", as
we do with PRECOMPILED_HEADER entries.
Fixes: QTCREATORBUG-17569
Change-Id: Ie0e6efdd09715daf2802b126a4ecbdc20b25d008
Reviewed-by: Eike Ziller <eike.ziller@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>
... by a non-mutating .stringAppended, doing the same.
Change-Id: I7adb6cae3415942cc9a80088bd75cda9d577d4a5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
More consistent with the fromString case and avoiding false
conversions QString -> QFileInfo -> FileName in case the
inheritance of QString suddenly disappears.
Change-Id: Ib14646ab1a660fd45dd1ea6862a0b5faa52ad0e3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... when setting up extra compilers.
For example, the code model was not able to resolve included ui_*.h
files in a project that wasn't built yet, if the respective FORMS
declaration came from a .pri file.
Fixes: QTCREATORBUG-22395
Change-Id: I75c4b2b38fec209519adb563d579ecd3a17fe042
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When a file is saved, the directory is also touched. If files are not
added or removed, it is not necessary to reparse the project.
Change-Id: I718db68362d41ba936629be880f739ad79b8cb6f
Fixes: QTCREATORBUG-22361
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... in the pro file editor.
When the user selects "Jump to file under cursor" (e.g. via F2), and the
string under the cursor is not resolvable as a local file path, we
assume it is a CONFIG value and try to locate a corresponding prf file.
To this end, we expose the "feature roots" information of the qmake
evaluator in the QmakeProFile class.
Fixes: QTCREATORBUG-15753
Change-Id: Ibdc6e194a40f07030a5d21f2ddc7b92b63d1765b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Under certain circumstances, the file system watcher in the qmake
project parser keeps emitting the directoryChanged() signal even though
there seem to be no changes on the file system. Make sure we reparse
only if the directory timestamp has really changed.
This amends 76262814b6.
Change-Id: Ibdcd1e8405a49e78528bf5903e7caafc371cad1b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The idea is that some of the more intrusive prf files in Qt can skip
themselves when they encounter this condition.
Task-number: QTCREATORBUG-17521
Change-Id: I09a33b2d3c5dee1232803d46c521cc9fd29e1898
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If the user wants to indent with tabs, then consider that when adding
source files via the UI. But try not to mix: If the respective variable
already uses a different indentation consistently, then keep using that
one.
Fixes: QTCREATORBUG-8016
Change-Id: I037c9ac4d4e7fbbe5753a846e57d938bbb440d6a
Reviewed-by: David Schulz <david.schulz@qt.io>
Don't blindly append to the end of the list, but try to put files into
the right place with regards to lexicographical order.
We do not re-sort existing file lists, nor do we attempt to be fancy
with strangely formatted project files. But lists conforming to our own
style will stay sorted, in particular lists that have only ever been
touched by Qt Creator.
Fixes: QTCREATORBUG-553
Fixes: QTCREATORBUG-21807
Change-Id: I15db0e867a2d477fcf95e008f98ba468dcd83e45
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
...for the qmake project manager.
When parsing the project files, remember whether a file was discovered
by the exact or cumulative parse. Only files that were discovered by the
exact parse are considered "active" and thus part of the build
configuration. The others are not offered for selection.
Fixes: QTCREATORBUG-16016
Started-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I7a28b4de15e048975d7f0cd737dd8c11f744315b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These are not used during parsing but when operating on the items
in the project tree.
This loosens the ties between the qmake related parser and project
nodes.
Change-Id: I077356fcde240df56b466c71c902c821c4885f6d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The build directory can be "empty" if there is no build configuration,
or if the build configuration's build directory is empty.
Handle both cases in the same way.
This avoids passing an actually empty build directory to the parser,
which the parser does no longer handles gracefully on Windows.
If the build directory is empty, use the project's source path (instead
of QDir(QString()) which is the current working directory), which makes
it consistent with the behavior when actually building in that case.
The parser does not actually write files to disk, so there is no issue
with temporarily using that directory and later switching to a shadow
build directory.
Task-number: QTCREATORBUG-20121
Change-Id: Ia454085edae6b55b445cc5cf0ec3ae1c85464b0c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
It is often possible to user (member) functions or members directly.
That improves readablility and potentially reduces the total number of
symbols.
Also use qobject_container_cast at places where it is appropriate.
Change-Id: Ia2591bca356591e001e2c53eeebcf753e5bc3c37
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
When system include paths are added via QMAKE_CXXFLAGS in a .pro file,
in order to use the -isystem parameter, they are not taken into account
by Qt Creator.
This patch adds support for -isystem parameter in QMAKE_CXXFLAGS
parsing.
Change-Id: Ibd25734ec9f3a18258c445804c4a17269d7522ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This feature in question is the availability of the "Run" button in the
context menu of certain project nodes in the project tree to run
something presumably related to/build from that (sub)project.
Previously, the decision was made for certain qmake based projects
(those targeting Desktop, iOS and VxWorks) by some indirection
through the corresponding RunConfigurationFactories.
The patch lets the RunConfigurations decide themselves directly
and removes the indirection, potentially opening the feature for
other qmake based RCs, as well as other combinations (e.g.
PythonRunConfiguration could be associated with its .py file,
without the need to have a dummy project)
Change-Id: Ic489bd1dfa25fcd9102ffa4fa30125565dd2e40e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The strings remember in which file they were created/assigned.
However, this used a non-counting reference to a ProFile, which could
become dangling. If a subsequent ProFile re-used the exact same address,
a string's source would be mis-identified, which would be fatal in
conjunction with discard_from().
Since we actually need only a unique id for comparison, let's use an
integer for that.
comment on cherry-pick: this is actually a lot more than a cherry-pick,
because the file ids need to be aware of the dual VFS which was
concurrently introduced on the qtc side.
Started-by: Simon Hausmann <simon.hausmann@qt.io>
Change-Id: I395153afaf7c835d0119690ee7f4b915e6f90d4a
(cherry picked from qtbase/190aa94be7f5e146bef44862b974d733755cec85)
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Do not report success of a qmake parsing run based on every .pro-file
having reported success. Take the top-level .pro-file's success value
instead.
This fixes e.g. Creator, which has some .pro-files that error out in
some conditions.
Task-number: QTCREATORBUG-18992
Change-Id: I888141e723da84fb780ccd84c86acc25d03f5f28
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Avoid needless detaching in that method: The method is used less since
the Nodes no longer need to go through it. All the runconfigurations
still use it, so this change is still noticeable.
Change-Id: I9f5e238ab1ef7165fd4fef1b0f80d4e5daa9a7e8
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The patch broke defining the correct executable for qmake based
projects. Loading more complex projects (like QC itself) did
end up failing to run any executable out of the box as the
executable name was always wrong.
This reverts commit 21b0e7c37e.
Change-Id: I471c9963bd739b74e48286e1bde00f7222b90c8b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Finding the right pro-file was surprisingly slow. Make that fast again.
Task-number: QTCREATORBUG-19131
Change-Id: I4b5a8887cb13c36273a553f935a00d87cee4a7b5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
