The chooser allows choosing variables from a list, and inserting them
into previously focused line edit, text edit, or plain text edit.
Variables are now registered with a description in the variable manager.
Also make the QT_INSTALL_BINS --> CurrentProject:QT_INSTALL_BINS for
consistency.
(Cmake/Qt4). Use PluginManager invocation facility
for the form class code generation. Do the rest
(testing for form editor, retrieving the editor
contents).
Acked-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
This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.
We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.
We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.
The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.
Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration
Re-introduce FormWindowEditor as IEditor used for
Designer. Use SharedTools::WidgetHost directly
for embedding into FormEditorStack, doing the
geometry-changed handling in there as well.
Pass around contents as string, saving repeated
invocation of FormWindowEditor::contents().
Remove dependency to FormWindowEditor.
Reviewed-by: dt <qtc-committer@nokia.com>
* Ease cross device development by introducing 'targets' which
group build- and runsettings that are valid for this one target
Most of the kudos for the code review go to dt. Con, thorbjorn,
ckandler and others did also review parts of this patch.
Reviewed-by: dt
They do what you expect them to do, that is build only a subtree.
The implementation is a little bit strange. We temporarly set the sub
node to be built on the BuildConfiguration, enqueue that
BuildConfiguration (which calls BuildStep::init()), and then reset that
temporary value.
A more general way would be to have the ability to extend
BuildConfiguration::buildProject() in a way that additional data can be
passed to the BuildSteps.
Task-Nr: QTCREATOR-5
Task-Nr: QTCREATORBUG-44
Enables users to change which buildsteps get run per buildconfiguration.
Some further tweaks are probably necessary. This is a rather big
change, though it should work. :)
and ApplicationRunConfiguration to LocalApplicationRunConfiguration,
preparing remote debugging. Change the interface canRun() to be const,
run() to create() (since it does not run anything), use references
to the QSharedPointer<Foo>. Introduce d-Pointer and remove
unneeded headers from ProjectExplorerPlugin and add missing includes
everywhere.
