Refactor ToolChains in Qt Creator:
* Allow for several toolchains of the same type
* Be smarter wrt. guessing what kind of output a toolchain
produces. This allows us to eventually handle e.g. embedded
linux setups way better than before.
* Be smarter wrt. guessing what kind of environment a Qt version
needs.
* Improve auto-detection of toolchains a bit
* Decide on which debugger to use based on the kind of output
produced by the compiler.
* Add options page to configure toolchains
* Remove toolchain related options from the Qt version dialog
Reviewed-by: dt
qmlviewer is picky about file path capitalization, and will bail out with
'File name case mismatch' if e.g. the working directory is wrongly
capitalized. Prevent this by computing the canonical path of
the qml file + working directory in advance.
Reviewed-by: Alessandro Portale
Task-number: QTCREATORBUG-3417
The mainFile property of QmlProject is the default file to run. People
have still the opportunity to override this in their run settings,
though.
The wizard generated code was updated accordingly. Note that this makes
projects generated by the wizard incompatible with QtCreator 2.1!
Task-number: QTCREATORBUG-3249
There are probably very little use cases where you want to start
from a clean environment, and there is no such thing as a Build
Environment (although we magically add some toolchain settings to
the environment).
get away from argument stringlists. instead, use native shell command
lines which support quoting/splitting, environment variable expansion
and redirections with well-understood semantics.
Task-number: QTCREATORBUG-542
Task-number: QTCREATORBUG-1564
We're using a QObject property to get the Qt Version Id: QmlDumpTool
is in Qt4ProjectManager, which shouldn't have a dependency to QmlProjectManager.
Reviewed-by: Christian Kamm
QmlObserver right now requires 4.7.1 minimum. There's no gain in
telling the user that he needs qmlobserver to debug, if it can't be
build with 4.7.0 anyway.
Reviewed-by: Christiaan Janssen
Moved qmljsdebugger to a dir under qml/, made qmlobserver compile
without creator dependencies and made it compile with debugging
helpers.
Reviewed-by: hjk
There's a UI in qml/customexec/cmake/qmake run configs for choosing the
debugger languages (C++ and QML). The default for all except .qmlproject
is only C++, so default debugging behavior is the same. However, if the
user wants to do simultaneous debugging with two languages, or only
debug QML, they can select the languages from Run Settings and it will
be remembered.
Reviewed-by: hunger
Don't misuse the input field for a custom qmlviewer path with displaying
the effective qmlviewer used. Previously the effective qmlviewer was
only calculated when the project pane is shown first, and then never
updated.
Reviewed-by: holmstedt
If no 'qmlviewer' executable is found in the PATH, iterate through the
list of configured Qt versions and try to find a qmlviewer there. This
should help users configuring creator such to play with Qml.
Right now the first qmlviewer found in a Qt version is selected. A UI
to let the user select one explicitly was not possible any more (string
freeze).
This requires a dependency from QmlProjectManager to
Qt4ProjectManager.
Reviewed-by: dt
Move link handling code to outputwindow from OutputFormatter
Move createOutputFormatter to the RunConfiguration
That makes it easier for Qt4RunConfiguration et all.
This also fixes that each time a runcontrol was rerun a new
OutputFormatter was created without deleting the old one, thus
increasing the memory usage.
The heuristics to find the file to run and the logic that decides
whether the show / debug button is shown weren't in sync. Also, don't
try to run .qmlproject files if open in the editor.
Reviewed-by: Lasse Holmstedt
By introducing the OutputFormatter, RunControls can influence the formatting
depening on the application started. A nice (and intended) side-effect is that
the QML runtime specific formatting will not interfere anymore with anything
else.
