"src/plugins/qnx/blackberrydeviceconfiguration.h" did not exist on "05866e796c85f6d0e8cedf730072cb9c786f1007"
- Apr 07, 2010
-
-
dt authored
-
- Mar 25, 2010
-
-
dt authored
-
Tobias Hunger authored
Reviewed-by: dt
-
- Mar 22, 2010
-
-
con authored
Reviewed-by: dt
-
- Mar 17, 2010
-
-
Friedemann Kleint authored
-
- Mar 11, 2010
-
-
dt authored
-
- Mar 10, 2010
-
-
dt authored
-
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
- Feb 17, 2010
-
-
Tobias Hunger 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 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 01, 2010
-
-
Tobias Hunger authored
* That is what everybody else is using now. Reviewed-by: dt
-
Tobias Hunger authored
* This makes it easier to distinguish projects in the userfileaccessor
-
Tobias Hunger authored
Reviewed-by: dt
-
- Jan 12, 2010
-
-
dt authored
QMake passes those headers directly to gcc, so the user doesn't need to include themselves.
-
- Jan 11, 2010
-
-
dt authored
Reviewed-By: con
-
- 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 22, 2009
-
-
con authored
This code was (more or less) duplicated in 4 places.
-
- Dec 09, 2009
-
-
Oswald Buddenhagen authored
-
- Dec 08, 2009
-
-
dt authored
-
Oswald Buddenhagen authored
there is no point in throwing away and re-recreating invariant data over and over ... shaves off ~15% of the load time of Qt 4.6.
-
- Dec 07, 2009
-
-
dt authored
Should fix a lot of corner cases, might introduce a few bugs. Also rename functions/slots to be better named. Generic Project Manager and CMake Project Manager are missing from this patch.
-
- Dec 03, 2009
-
-
Friedemann Kleint authored
...making use of the new code model features. Move code to separate file. Make it possible to obtain path to generated header file from project manager.
-
- Nov 30, 2009
-
-
dt authored
-
dt authored
-
dt authored
Note: I didn't fix all the connects and there are a few missing things. This compiles, more work is coming.
-
dt authored
The pointers can be used to distinguish BuildConfigurations
-
dt authored
More API work.
-
dt authored
Each project has it's own BuildConfiguarion * classes, they'll get a decent type safe interface and the setValue/value stuff will be removed.
-
- Nov 19, 2009
- Nov 10, 2009
-
-
dt authored
-
- Oct 29, 2009
- Oct 22, 2009
-
-
dt authored
That is we actually parse the mkspec and evaluate QMAKE_CXX (and a few other variables) to figure out the correct mkspec. This makes using custom mkspecs easier and is also cleaner. I also changed mkspec() and mkspecPath() to behave a little diffrent, essentialy mkspec() will return only the name (the actual dir name) of the mkspec. That is in general not sufficient for passing on to qmake. mkspecPath() only returns the correct path to mkspecs/default. Hopefully I haven't broken WinCE/Maemo/MinGW.
-
- Oct 09, 2009
-
-
con authored
Reviewed-by: dt
-
- Oct 01, 2009
-
-
con authored
It's easier this way for the unique naming.
-