- Mar 25, 2010
-
-
Tobias Hunger authored
Reviewed-by: dt
-
Tobias Hunger authored
... use it. Reviewed-by: dt
-
- Mar 17, 2010
-
-
Friedemann Kleint authored
-
- Mar 16, 2010
- Mar 12, 2010
-
-
Thorbjørn Lindeijer authored
The functionality was duplicated between the Qt4 and CMake build configurations and their configuration widgets. This change moves it down to BuildConfiguration, in addition also making it available for the Generic Project. Also provides an upgrade path for the configuration. Task-number: QTCREATOR-24 Reviewed-by: dt Reviewed-by: Tobias Hunger
-
- Mar 10, 2010
-
-
dt authored
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
-
- Mar 05, 2010
-
-
hjk authored
-
- Feb 19, 2010
-
-
Tobias Hunger authored
* Add qWarnings on failures.
-
- Feb 17, 2010
-
-
Friedemann Kleint authored
- Autodetect SDK by environment variable EPOCROOT and qt directory below. - Environment::appendOrSet/prependOrSet: Avoid duplicate entries - Rename toolchain enumeration value - Adapt S60ToolChainMixin to new GnuPoc setup, provide routines for all required variables. - RVCTToolChain: Make RVCT detection smarter (Check for RVCT<v1><v2>BIN variable). Set all required variables in case of RVCTToolChain/GnuPoc - QtVersionManager: Detect toolchain and Qt version properly, make S60 device run config accept toolchain. - Modify S60DeviceRunControl to execute 'make sis' - Modify S60Devices::detectQt...() to check for Qt installed into SDK first and symlink as fallback.
-
Tobias Hunger authored
when not set to true in the .user-file.
-
Tobias Hunger authored
* Remove default Qt version from list of available versions
-
dt authored
-
- Feb 16, 2010
-
-
Tobias Hunger authored
* Do not use the BuildManager but have the qmakestep trigger the update via the target and project. Reviewed-by: dt
-
- Feb 10, 2010
-
-
Tobias Hunger authored
-
- Feb 09, 2010
-
-
Tobias Hunger authored
* 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
-
- Feb 02, 2010
-
-
Friedemann Kleint authored
QString: Use QChar/char where appropriate, do not use QString::null
-
- Feb 01, 2010
-
-
Friedemann Kleint authored
QString: Use QChar where appropriate.
-
Tobias Hunger authored
* That is what everybody else is using now. Reviewed-by: dt
-
Tobias Hunger authored
Reviewed-by: dt
-
Tobias Hunger authored
* Make use of the ProjectConfiguration base class in the BuildConfigurations and update the factories accordingly. Reviewed-by: dt
-
- Jan 13, 2010
-
-
dt authored
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
-
- Jan 12, 2010
- Jan 11, 2010
-
-
Tobias Hunger authored
Reviewed-by: thorbjorn
-
- Jan 07, 2010
-
-
Tobias Hunger authored
* Use id() for methods returning a string used to represent some type of object. * Use displayName() for strings that are meant to be user visible. * Quieten some warnings while touching the files anyway. * Move Factories to their products in the plugins where that was not done before. Reviewed-by: dt
-
- Dec 17, 2009
-
-
con authored
The only part that is not done if not on Windows (or explicitly specified) is the adding of the preference pane.
-
- Dec 14, 2009
-
-
dt authored
Task-Nr: QTCREATORBUG-277
-
- Dec 08, 2009
- Dec 07, 2009
- Dec 02, 2009
-
-
con authored
Move the code that compares the Qt version's debug|release property with the build configuration's debug|release property to the new build configuration class. Reviewed-by: dt
-
- Nov 30, 2009