Local executable is put into a different folder
(always 'armv5' despite it being a 'gcce' build, changed in qmake),
and the symbol file is named 'foo.exe.sym' instead of 'foo.sym'.
Done-by: Friedemann Kleint
Reviewed-by: Pawel Polanski
Local executable is put into a different folder
(always 'armv5' despite it being a 'gcce' build, changed in qmake),
and the symbol file is named 'foo.exe.sym' instead of 'foo.sym'.
Done-by: Friedemann Kleint
Reviewed-by: Pawel Polanski
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
* Enable support for this in all ProjectConfiguration items
(Targets, projects, BCs, DCs, RCs, etc.). This is nicer
than having custom code in individual configuraiton items.
Reviewed-by: dt
Fix breakage introduced by the new asynchronous stop() methods
of the debugger run controls. Allow for RunControl::stop() to
be asynchronous by introducing a return enumeration indicating
that. Introduce additional method aboutToStop() asking user
to quit (tie that to the RunControl instead of having to hack
the behaviour elsewhere).
If asynchronous stop is detected, terminate the ProjectExplorer
asynchronously.
This makes the behaviour consistent across switching sessions/
closing outputwindow tabs and quitting Qt Creator.
Reviewed-by: dt
Rubber-stamped-by: hjk
* Add a DeployConfiguration class to hold settings related
to deployment.
* Add BuildStepsList to hold a list of buildsteps
* Update BuildConfiguration to use BuildStepLists instead of
manageing lists of buildsteps itself.
* Update BuildManager to use BuildStepLists in its interfaces
* Fix fallout introduced by API changes
* Update .user file to new way of storing settings
Task-number: QTCREATORBUG-1427
Task-number: QTCREATORBUG-1428
Task-number: QTCREATORBUG-1811
Task-number: QTCREATORBUG-1930
We create a .sis package per leaf project now, deploy all of them and
start the executable for the runconfiguration that was selected. This
does not cover all use cases, but works for development.
* Add buildstep to handle the deployment
* Remove deployment code from the runconfiguration
* Update .user files to add new deployment step into existing setups
Reviewed-by: Tobias Hunger
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.
This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.
DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.
There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).
This replaces most uses of DebuggerStartParameters by DebuggerRunControl
which is a simple RunControl with a DebuggerStartParameters member.
Plan is to move all global state to the run controls, and possibly
introduce specialized ones for core debugging etc.
And use it to implement changing the run icon in the application output.
That implementation does only support the two run modes run and debug
for now. Further abstraction for more run modes to be done once needed.
Task-Nr: QTCREATORBUG-1232
