qt assumes that it is being installed (possibly into an install root),
not deployed, and leaves the translation of host paths to device paths
to the deploying agent - which is qt creator.
Task-number: QTCREATORBUG-17466
Change-Id: If9065b1079df607732e0f81132f29dbaf18ff602
Started-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... instead of having to remove/add. Use it in some places
in QmakeProjectManager and the ResourceEditor where the
(sub)tree is rebuild anyway.
Change-Id: I46b3c078c576b72dba6e87432570d030b7572026
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The FlatModel is essentially a proxy model keeping expansion and
filter state per ProjectTree(View). Using a Utils::TreeModel makes
it fast enough to allow recreation of the proxy structure on
structural changes simplifying the parent/child logic significantly.
The {Session,Project,Folder,File}Node hierarchy still is still primary
information and shared by all views.
Change-Id: Ic08180a19bda37908280ff30e0737d188ed93e92
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... in subdirs projects which actually have any subdirs.
that would happen via this mechanism in QmakeProFileNode::evaluate():
first, IncludedPriFile nodes with proFile = null are created for the
subdirs. subsequently, this tree is enriched by transforming the
reader's included files. that loop iterates over all already created
nodes and tries to match them against included files. at nesting level
one, this would now run into the nodes created for the subdirs. the code
failed to skip over these nodes, and would thus create a bogus node for
the .pro file (as it has the parent null in the mapping of included
files). this node would not be included into the tree due to the loop
prevention in QmakeProFileNode::applyEvaluate() (it obviously had the
same file path as its parent), but at the same time it would catch the
files meant for the root node due to defeating the fallback in
QmakePriFileNode::extractSources().
Task-number: QTCREATORBUG-17473
Change-Id: Ice9f667345148be42297cc21ff0a73058f27cc38
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
When performing mechanized editing on .pro/.pri files, until now, Qt
Creator reloaded and restored the file with [from|to]Local8Bit.
That broke #comments in unicode.
This change implements that the the "Default encoding" from the text
editor options is used instead.
Task-number: QTCREATORBUG-10274
Change-Id: I783fc3a2c6a2638e4603ced2eef25c2a3998e2c1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Make priority available on all FolderNodes. Make the sort order
of all kinds of FolderNodes check the priority.
This allows no reorder e.g. ProjectNodes as needed.
Change-Id: I369edd28807ab9f89fb646b0001e1b3eb1a19d7e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
ProFileNodes start out as "no parse in progress" and need to be told
that there is a "parse in progress" when created as part of the project
parsing.
Otherwise they will not notify their associated run configuration that
they are done parsing, which in turn keeps the run buttons in the UI
inactive.
Change-Id: Ic37a9f1ccb6beecbf37f4fc54747122572e52c90
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Correctly signal when parsing of a qmake project starts and stops via
the build- and runconfigurations.
The buildconfigurations are in the picture since they disable the run buttons
when the user has selected to build before deploy and deploy before run.
Task-number: QTCREATORBUG-16172
Task-number: QTCREATORBUG-15583
Change-Id: I44b5f5ce8e145cb93dc0022f66e1edcc202875e4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use class enum to shorten the FileType to quint16. This frees up a couple
of bytes per FileNode and we can have many of those.
Change-Id: I3a9ae25059690fefa15305a4268269647d6dc1c9
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use a class enum with a type quint16 for the NodeType. Frees 2 bytes
per node that can be used for better things now.
Change-Id: Ib84bf8629e9f4a5fb0793355eff0f0d6302167dd
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
don't fail to make the build pass evaluator cumulative as well.
Task-number: QTCREATORBUG-17214
Change-Id: I217578b7d29d0dcf9ef63c954ec403412812c70c
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
don't resolve the source files once for deployment and once for the
project tree.
Change-Id: Ifddf8fc7883bf025d3640de0d6676b5930991088
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
instead of resolving all sources both in the exact and the cumulative
pass and de-duplicating the joined list in the end, resolve only these
files from the cumulative pass which are unique to it to start with.
Change-Id: Ie3327799ecd94f8710f8b99bcc46998790ba2c74
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
rather than resolving them once in bulk (for the code model) and once
per pri file (for the project view), resolve them only in bulk, but
"tag" them. then do a cheap filtering pass for the project view.
as a side effect, this fixes the problem that sources that are listed by
a file that is not shown in the project tree (as is the case for qrc
files synthesized by resources.prf) would not be shown at all. instead,
these sources now appear belonging directly to the pro file.
Task-number: QTCREATORBUG-3670
Change-Id: I1a1756d95bd90db4da1274eebcc4dad2a854f43d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
so far, we used a build pass only to retrieve accurate target
information from the exact evaluator. however, this is insufficient for
at least two reasons:
- the recently introduced postprocessing of RESOURCES in resources.prf
is executed only during build passes
- some relevant variables are build pass specific, for example
INCLUDEPATH when it includes RCC_DIR
an additional upside is that using the build pass' values is consistent
with qmake's vcxproj generation mode.
on the downside, the extra cumulative build pass adds 33% of pure
project evaluation time. however, this isn't as bad, as the pro files
are already loaded and parsed, and the expensive source file resolution
moves completely to the build pass.
the alternative of defeating the build pass logic (as lupdate does) is
not feasible, as we rely on accurate target information from an actual
build pass for the run configurations.
note that this all applies only to windows (and macos when explicitly
configured with -debug-and-release).
Task-number: QTCREATORBUG-16019
Change-Id: I8a97856b3b738aa1a581d24ba24bb3e7199d8078
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
consistently with Xcode, qmake nowadays knows only one SOURCES list,
which is automatically classified by extension.
to replicate that, we actually copy the objective_c.prf file from qt
5.6.3 and use it to override whatever comes with qt, so we can treat all
qt versions uniformly.
also, the code model throws away the information which files were listed
as sources and which as headers. this is technically incorrect, as a
source may be only included rather than compiled, but there is no point
in extracting information which is not used.
conclusion: lump all c-like sources into one variable as far as project
processing is concerned.
and as far as configuration goes, our code model doesn't differentiate
anyway, so the duplicated setup paths can be eliminated as well.
Change-Id: I24b1bc056f8d9eb579c9378817f602912ab49971
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
each such object has exactly one associated ProFile if it shall result
in a pri node, and no ProFile if it shall result in a pro node. there is
no point in dealing with lists at various levels.
Change-Id: I930fd8c14fcd6336cd297bacefdd0036f556741b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
the cumulative evaluation has a good chance to make a mess of the
virtual file contents created by the exact parsing, so better contain it
to its own namespace.
the ProFile cache also needs to keep the files separate. this
specifically addresses the side issue discussed in QTCREATORBUG-10779.
it also fixes attempts to deploy the wrong build when the variant is
selected through a cache file, as in QTCREATORBUG-15815.
in the project explorer, we don't track from which evaluation pass
particular files came from, so we try the cumulative first to get the
most contents, and fall back to the exact one if the former file is
empty (or does not exist at all).
Task-number: QTCREATORBUG-15815
Change-Id: I2c1eb16c97526fa275a1c6a2eae9266d385859ac
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
ProFileEvaluator::absoluteFileValues() now returns only files, which
allows us to skip the subsequent QFileInfo::isFile() calls at some
call sites.
as a side effect, IoUtils::fileType() does not see anything except
regular files and directories any more. that's not expected to be a
problem, given the function's scope.
Change-Id: I53063ad8cacb3afe5cc1baf6d6d5feba3465e74f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
qmake doesn't do anything with sysroots at this level, so this code
plain does not belong here.
sysrootification is used when resolving INCLUDEPATH, which is emulating
compiler behavior. this is done by higher-level code.
Task-number: QTCREATORBUG-11944
Change-Id: Ia25f0b6ef713e9809d974e3f3e49ba308b8c933f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... and use it for PRECOMPILED_HEADER, INCLUDEPATH, and install target
collection, instead of abusing ProFileReader::absoluteFileValues().
specifically, this falls back to a location in the build directory when
the path is relative and the file cannot be found. in qmake, this
somewhat weird behavior ensures that chaining extra compilers actually
works (and also ensures a lot of frustration with non-clean source dirs
...).
this also fixes INSTALLS with .CONFIG no_check_exists.
Task-number: QTCREATORBUG-14848
Change-Id: Iaf9483c0c4586c464bd10a2aea7cbac7e0df1ec5
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
no-one ever queried this state since S60 support was removed in
ae23d50576 (2012).
Change-Id: I3e05d90bb43514b4c326e124834cf9c5e89a0168
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
since fa6d0f1231, DEPLOYMENT is aliased to INSTALLS, so we would have to
actually look for .sources in entries listed in that variable, which we
didn't. apparently, nobody noticed, among other things possibly because
the qt4 variant already supports .files in later versions.
also, our actual deployment code doesn't use .sources, either.
Change-Id: I990240716817118047fc9aa97eff55305fcf7eca
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
we *know* that this function is called only with folders; it's part of
its api.
Change-Id: Idada1e6672a916c0d550d191770396ebbc54b02f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
we actually use variable values only from the exact reader, based on the
idea that the cumulative parse is too dangerous, as using recursive
watches on inexact data may be a bit heavy. using additional variable
names from the cumulative reader sort of defeats the idea.
Change-Id: I8bf3e298bf89593dcc77548cc3d2cbf7881202dd
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
moc.prf also adds an extra compiler which takes SOURCES as input. as we
add it to the list manually, we have to filter it just like HEADERS.
Change-Id: I81b8b68965c1b65fd0cef6a68c01ad00d51d6dee
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The user can set QML_DESIGNER_IMPORT_PATH to define
a qml import path just for qml2puppet.
Change-Id: Ic9dac4cf478c9d0f8d6e066d6a9a481500cc5497
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
the only place where this actually saves a deep copy is the evaluation
of if(), but as a side effect the parser is now able to deal with not
null-terminated strings, which is kinda nice as well.
Change-Id: Ib6d08617aa79d2f9eaecd4906d4d548f34bf377d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
(cherry picked from qtbase/ad17a35853fe21a93fc34f7b2d9262c5ac992b29)
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This allows us to easily add scxml files to a qmake project.
Change-Id: I2b5b21683f3e76062e6858fb8d0bceaa699a5569
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
