... 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>
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>
This is necessary, if the project files on a
different directory than the source files. In this case, the project
explorer will show the full path e.g. in windows starting by C: for each
directory until the source files.
use-case:
some directory
|- project directory
|- *.creator & *.files & ... generic project files
|- source directory
|- some sub-directories and the source files
Fixes: QTCREATORBUG-19454
Change-Id: I95eee4afdc11adf4281220edc5f6ff29da41a3a5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
This provides correct deployment information as seen by the build system
when Qt Creator cannot retrieve it directly.
It's most useful for autotools and cmake projects, but can also help
with qmake in certain edge cases.
[ChangeLog] It is no longer necessary to provide a
QtCreatorDeployment.txt file when using CMake projects with remote Linux
devices.
Fixes: QTCREATORBUG-21855
Change-Id: I27e07a45dd1565e489f4b573cc3fff8191c57d9b
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Use setter of base class, similar to setListInProject() before.
Change-Id: Id620f0084a5dec0410f29c80f8f6393a6bcd5050
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
...in order to specify e.g. the language version to use.
Create the additional files project.cxxflags and project.cflags. These
are expected to contain command line flags for the clang code model on
one single line.
For example, "-std=c++11" can be provided to set the language version
for parsing.
Fixes: QTCREATORBUG-19668
Change-Id: I7712f546ba1fae536c32adfa5bd449c5b3484521
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Centralize gathering the kit, toolchains and qt version.
Change-Id: I6bd586ac7925e2ee556fd119f1dab096cd500e41
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The cancel methods were called just before setting up the parameters
for the CppProjectUpdater::update() call, which calls cancel() as its
very first action.
Change-Id: I748cb4daa86bc8245cd906b2dff3c7b2d50795b2
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
We use the same approach as for CMake, namely the
QtCreatorDeployment.txt file.
Fixes: QTCREATORBUG-19202
Change-Id: I50605b8236b26f0c911e2448330019e94753af19
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
We checked the command line from the project manager for "-std=X" and
friends to figure out the language version to use. However, if such a
flag was not provided, we assumed the latest version we support. This
could conflict with the actual version of the compiler and its
predefined macros.
Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the
predefined macros of the toolchain. The MSVC compiler is an exception to
this, as it does not seem to properly set the value - check for
_MSVC_LANG if possible, otherwise simply assume some versions as before.
While at it, add also support for C17/C18 and the upcoming C++2a.
Task-number: QTCREATORBUG-20884
Task-number: QTCREATORBUG-21188
Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
pos was -1 for a value that should have been appended as
last element to the list. Unfortunately, list->insert
treats -1 as prepending in front of the list, which lead
to incorrectly sorted lists.
The function got broken during the review process of
the introducing commit 758544c058.
Change-Id: I693e4d79b0d493deeac0ea8781d637fe50d008b8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As a first step of creating a generic base for the 3 existing
implementations.
Change-Id: I2456db74cb635316f97a247e2a2b6bdb34931440
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Most other signatures look like {...}RunConfiguration::initialize(Core::Id),
make this here the same, even if the Id is unused (or, rather always
the same) so we can use a virtual function in the base RunConfiguration
at some time.
Change-Id: I5d3d4a7bf856bb0cc31f8e26bc0e5a80fd1a4066
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The idea is to massage the setup in a way to make implementation
of new configurations less error prone by identifying recurring patterns
and sharing repetitive code that tends to be forgotten (see Android cloning).
The former two lines of constructors (owner-and-id, owner-and-source)
are split into a simple, shared, constructor and new setId() and
copyFrom() functions.
The change is mostly mechanical, some multiple calls to fromMap
have been removed, though, some consts added.
Otherwise, to keep the patch small it temporarily introduces two
helper templates in IRunConfigurationFactory. Also, setId() signatures
have not been unified yet. These won't be needed in the final setup.
Change-Id: I8c0734496caae744a9883fe6d92c1d8f8e0234ea
Reviewed-by: hjk <hjk@qt.io>
qmake from Qt4 does not provide C++ standard and
clang can't properly compile Qt4.8.6 and earlier
with c++1z. Behavior in this commit mimics qmake
from Qt5 which also provides c++11 as a default
standard.
Task-number: QTCREATORBUG-16441
Change-Id: I3d29891d6e47f2367f2b3b2bf4be4d86661924e9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Unify the handling of displayName with a proper changed signal across
all projects.
Change-Id: I7e503528854b85f6f38de4b0943775f82a0d6123
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Handle the generation of the list of files in a project globally, based
on the project tree.
Creator now has the concept of TreeManagers which can enrich the project
tree with additional data (e.g. the files found in a resource file), which
the project does not necessarily know about. So use that tree to find
the files that belong to a project instead of implementing similar features
in each project.
Change-Id: Ia375a914a1f2c0adaa427f9eda834eec2db07f68
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Marco Benelli <marco.benelli@qt.io>
Remove unused code from project node, access own members
directly, etc.
Change-Id: Icbffb4d3328757ffe3aa756ca1448fefba9bb00a
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Also, rename buildTree() to addNestedNodes(), it's really
adding things, not recompletely (re-)building the subtree.
Use it whenever possible to avoid intermediate lists of items
to insert.
Change-Id: I5fde41e5b164a8a292410bd381a85f5efadf3471
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Create an initial project tree with a ProjectNode and a FileNode for
the project file itself.
Fix the Projects to not implement their own tree before they have
better data.
Change-Id: I147ccd5603d22d1d60880a97f30fd8c271eac88c
Reviewed-by: hjk <hjk@qt.io>
Do not update the existing project tree anymore: Start a fresh one
and throw the old one away.
Change-Id: Ifabe293b6ca668b0672516a6d81acd5346d98fe5
Reviewed-by: hjk <hjk@qt.io>
Can be done generically when creating projects. The only wart is
the use from BaseQmakeProjectWizardDialog::writeUserFile.
Change-Id: Ie98c9f88ec142e82443e204a0075e3ae9e163752
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Do not call makeEmpty() as part of buildTree(). That makes it
impossible to combine buildTree with manual tree setup.
Change-Id: If0a0d9432fe39870917a6ba31594e8dcd6d31868
Reviewed-by: hjk <hjk@qt.io>
Before
commit 8c90998fff
CppTools/ProjectManagers: Reduce ui blocking when loading projects
the displayName was set in the ProjectPartBuilder constructor. Now this
needs to be done explicitly.
Change-Id: I67655a3a5b8052344084e467bb08efd07ab86ab4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
${AnyProject}::updateCppCodeModel() did two potentially not that cheap
operations in the ui thread:
(1) Querying the MimeDatabase for the mime type for the source files of
the project. In 99.9% of the cases no files need to be read for
this as the file extension will resolve the type. The expensiveness
comes from the sheer number of files that can occur.
(2) Calling compilers with the "(sub)project's compiler command line"
to determine the macros. While the caches avoid redundant calls,
the number of the unique compiler calls makes this still a
ui-freezing experience.
These two operations are moved into a worker thread. For this, the
expensive compiler calls are encapsulated in thread safe lambdas
("runners") in order to keep the "mutexed" data minimal. The original
API calls of the toolchains are implemented in terms of the runners.
While adapting the project managers, remove also the calls to
setProjectLanguage(). These are redundant because all of the project
managers already set a proper value in the constructor. Also, currently
there is no need (client) to report back detection of C sources in
project parts. This also keeps CppProjectUpdater simple.
There is still room for improvement:
* Run the compiler calls in parallel instead of sequence.
* Ensure that the mime type for a file is determined exactly once.
Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We don't need two IDs for C++ and the QmlJS ID should look the same as
as the others.
Change-Id: Ib9747f6b36a90bb652951d85eec69666615670c4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Now that the generic manager can use data from the target or the build
configuration for expanding entries in its projects files it is
important that it reacts to changes of these entities. A change in the
build configuration can change the include directories or even compile
flags stored in the project configuration and hence the C++ code model
needs to be updated to reflect such changes.
The code is based on the qmake's project manager which has similar
functionality as far as I understood. The only difference is that the
generic manager won't attempt to refresh its state in the background (as
it simply can't do that right now) so the ui will be blocked for a bit.
Change-Id: I0a85e1ff0deeb876a7934b9a193a5d0f020047c7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
