Rewrite the target setup page to look and baheve better.
Noteable better at:
- Disabling shadow building
- Deselecting whole targets
- Adding import directories
Api-wise, Targets derived from Qt4BaseTarget have two ways to customize
the targetsetuppage.
a) Reimplement availableBuildConfigurations
b) Leave createTargetSetupWidget and create(... Qt4TargetSetupWidget)
in their default implementation. (Or only slightly customize like
the desktop target does.)
Or:
a) Make a dummy implementation for availableBuildConfiguration
b) Replace createTargetSetupWidget and return your own widget
(It should match the look and feel from the other widgets.)
It needs to be derived from Qt4TargetSetupWidget
c) Also replace the create create(... Qt4TargetSetupWidget) function
and set up the target anyway you want.
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
Almost(*) all of the symbian and maemo specific code is now theoretically
moveable to a separate plugin. Thus making it possible to implement
new targets in a plugin.
(*) Noteable missing is the qtversion, which needs to be split up
per target too.
Also fixes
Task-Nr: QTCREATORBUG-2440
Reviewed-By: hunger
Reviewed-By: ck
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
* 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
Using more *::Constants::ICON_* where it makes sense and
wrapping the file names into QLatin1String where they were
missing.
The increased usage of the ICON constants needed a few more
cross plugin includes of *constants.h, here and there.
I think that it is OK, since the dependencies were alredy there
icon resource wise.
* 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
* Add "Deploy" to BuildSteps::Type
* Update UIs to handle deploy steps
* Turn existing package creation steps from build type to deploy type
* Move packaging steps into deploy steps when loading projects
Reviewed-by: dt
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
...making use of a shared device by all clients. Detect device removal by
delaying the WM_DEVICE event handling. Introduce Acquire/Release mechanism
to SymbianDeviceManager and let acquire() fail if the device is in use, thus
preventing starting 'run' while debugging is active, etc.
Handle "Device removed" (unplugging of cable) signal by closing the device and adding
handlers to the clients, stabilize TrkDevice against it.
Remove communication type from the run configuration parameters (now handled by
SymbianDeviceManager).
Working towards keeping the Trk-connection always open and a giving the target pane
a meaningful tooltip.
For the moment, pass on tooltips from device manager additional information
(Trk version and such as determined by the launcher).
