Check every project's path against the source paths of all existing qts.
If we find a match, make it build in the right place by default.
Works for both in source and shadow builds.
Note: There's a quadratic algorithm since foreach kit we check against
all qt versions. That's unlikely to be a problem and non trivial to
fix.
Change-Id: I9f3456f3e835ee6adc35c26fe5c328c01387a8aa
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
All static functions, can live closer to related code.
Change-Id: I54c5680256c78f1d09b4bee3e8843b2f4350b75a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
20 lines above we actually search for qml libraries in the .pro/.pri file.
Do not overwrite this just based on the fact that there are QML files listed
somewhere in the project.
Change-Id: I01ea4304d98e40fca690d5bf3ce3f3de0543c82d
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Do not set the timer interval while the timer is running.
Change-Id: If72eb77fed88a5dda3f6356b1bd82aab781b160d
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Fall back to what we do for Windows/Linux/BSD and the rest of
Unix anyway.
The target architecture/os detection process is conceptually
not precise. Refusing to do anything at all, including steps like
copying files which do not depend on precise architecture data
anyway, is overshooting.
Change-Id: Ic6c98c4dac5fe4a625149be558c8b02440f8fdbc
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Replace the CppModelManagerInterface/derived CppModelManager
combo by a more common CppModelManager/CppModelManagerPrivate
pimpl pattern.
Change-Id: Ia4582845ed94d5ef60b8571bab9b2260c6290287
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
.. because they now hold only files for a single language+extensions
combination.
Task-number: QTCREATORBUG-11709
Task-number: QTCREATORBUG-12818
Change-Id: If294f6de07d60126be733d98de12b89b8af3efce
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
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>
