Instead call it once per .pro file and pass that to all .pri file parses
and other functions. This cuts down the number of calls for opening
qtproject.pro from ~3000 to ~700 and speeds up opening qtproject.pro
by roughly 3%.
Change-Id: Iffd46d4bbedc9c380f70e916dae7151495990b39
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
So that recalculating the information is not O(n^2) but linear.
Change-Id: I69903e0b5ad321d071804d782ad634a3f300e71a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
The current approach fails for all build systems where one project file
can define more than one executable.
Change-Id: Ieda413975709fbd6e7ea87b185aa962f63cb7c1f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Instead of checking if a file is unique with a O(n) operation per file,
do one pass at the end after sorting. This makes opening qtproject.pro
roughly ~7% faster.
Change-Id: If30bdeb8f72e5b28fb900e8e7a45bddb5f9f7822
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
This is in preparation for changes to the ProjectParts, where one part
can only hold files for 1 language.
Change-Id: I0e69e0f174341054ed89273d288a78d9aa468d59
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Language::Enum -> QmlDialect
* class instead of enum
* moved Language specific operations to it (from Document)
* nicer handling
QStringList -> PathsAndLanguages
* store language along with path, to perform a correct scan and improve
path handling
Change-Id: If69d35c63cfeb48aa670b51870916cd0c40f1916
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@digia.com>
This removes qmakeprojectmanager and qmlprojectmanager dependency on
qmljstools.
Qmlprojectmanager still imports qmltoolsconstants.h for a constant
but that gives no runtime dependency.
Change-Id: Ifd2e76500a3b27a21937603925f03a70049900e1
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Instead of having two lists of paths, now only one list is used where
both include paths and framework paths can be mixed. This reflects the
way the compiler is invoked, and retains the (correct) search order.
Task-number: QTCREATORBUG-11599
Change-Id: I373953e3e305df5b7a0d10920e12d146584adf9f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
The QMake project didn't put them into files() anymore since qrc nodes
where made folders.
Change-Id: I8e9354699cfccc4fdd4f5ce39baa30a9d61ce051
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
This wizard is from a different era. Nowadays webkit is on the way
towards deprecation and the replacement isn't ready yet.
Change-Id: Ifac9a42463562fefaa4a33eb7be2a09e0d8af1aa
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
... and use ProjectExplorerPlugin::instance() directly in some places
where a variable was defined for it and used exactly once.
No code change.
Change-Id: I095fc80ac29f717eaabf13afa90c3bf6d9daf90a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The QMakeEvaluator uses it's own more accurate version of
isAbsolutePath. If we pass in a path that qt thinks is
absolute, e.g. "C:dev", but the qmake evaluator disagrees,
creator crashes. Import these functions from the qmake
evaluator into Utils::FileUtils and use them to prepare
the builddirectory.
Task-number: QTCREATORBUG-12034
Change-Id: Ida28688558f3186db25e3ab73bd39cabc91c1ff0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: David Schulz <david.schulz@digia.com>
While it is not possible to create a qmake kit without qt, the qt
version might become invalid and be removed.
Change-Id: I99484c86d731ab5a47bff9bb1958158504617004
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
On ios qmake is called recursively and the second call with a different
spec (macx-xcode instead of macx-ios-clang) which contains the
correct build settings (includes, compiler flags) as ios builds with
xcode.
macx-ios-clang just creates supporting makefiles, and to avoid being
slow does not evaluate everything, and contains misleading information
(that is never used), whereas macx-xcode correctly evaluates the
the variables and generates the xcodeproject that is actually used to
build the application.
It is important to override only for the creator evaluator, and not
the qmake buildstep used to build the app (as we use the makefiles).
Task-number: QTCREATORBUG-11908
Change-Id: I06d569de16f934fca5e104a8da727a3557a4c2e3
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Currently ModelManager contains lot logic, but as it sits in QmlJSTools
it is not possible to use it in standalone tests.
Moving most of the logic to ModelManagerInterface (and cleanup)
to allow better testing, and refactoring.
This introduces a dependency of the qmljs lib on the cplusplus lib
Also a (small) part of the CppTool::ModelManagerInterface has been
moved to CPlusPlus::CppModelManagerBase to remove the dependency on
CppTools to gather the Qml types exposed from C++.
Change-Id: Icad7fe96dfd0f1a2b1058d82bd98c77c40aa5e9d
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
So we can ignore possibly problematic toolchain-defines, while can still
unconditionally apply project-defines.
Change-Id: I7cb96f35a963d080011fe888ef71bfc098dd33ef
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
There's no target if the project is in the parsing without configuration
state.
Change-Id: Id21e2ded5b634253267e956accc27715e6562941
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
