summaryrefslogtreecommitdiffstats
path: root/mkspecs
Commit message (Collapse)AuthorAgeFilesLines
* Fixes build issue with WinCE and MSVC 2008 and MIPS-IIAndy2009-05-141-1/+1
| | | | Reviewed-by: Maurice
* Turn off Link Time Code Generation (/LTCG) by defaultMarius Storm-Olsen2009-05-133-4/+15
| | | | | | | | | | | | | Turning on LTCG affected too many projects, where customers applications would take a long time linking, severly affecting their development time (even though it was only added for release builds) We turn it off by default, and add a -ltcg configuration option, and the possibility to also do CONFIG+=ltcg in projects, should they not want it for Qt, but in their own projects. (Same, they can build Qt with it, and do CONFIG-=ltcg for their project) Reviewed-by: andy
* macx-g++42 spec linker was gcc instead of gcc-4.2João Abecasis2009-05-083-14/+9
| | | | | | | | Better alternative to 9ffcf3737901c49acb1a1bc6b65572d195d78a5d Task-number: 253052 Reviewed-by: Norwegian Rock Cat Reviewed-by: MortenS
* Make the g++-42 mkspec use gcc-4.2 for linking as well.Morten Sørvig2009-05-081-2/+6
| | | | | | Forgot to override the linker, causing it to use gcc 4.0. Reviewed-by: Richard Moe Gustavsen
* do not add UI_DIR to INCLUDEPATH if no FORMS are usedOswald Buddenhagen2009-04-201-4/+6
| | | | Reviewed-by: mariusSO
* fix compilation of QtWebKit with Visual StudioJoerg Bornemann2009-04-201-1/+6
| | | | | | | | | | | | | | | Commits 6e5774d84e7e3b68736f95fae09a084bd5b9ac7a and 014af3e99616f9ee13ca365566828f7daf77a7f6 broke the Qt build for Visual Studio / IncrediBuild. The problem is as follows: QtWebKit has too many entries in INCLUDE_PATHS. In moc.prf is a rule that builds a mocinclude.tmp that contains command line options for moc. moc gets then called with @mocinclude.tmp. Above commits create an QMAKE_EXTRA_TARGET for the mocinclude.tmp, which is necessary for parallel MinGW builds. Alas, qmake -tp vc doesn't support QMAKE_EXTRA_TARGET. See task 189914. Once this task is solved, this commit must be reverted. Reviewed-by: joao
* Fixes WebKit still occasionally failing to compile with MinGW whenRohan McGovern2009-04-151-9/+10
| | | | | | | | | | | | | passing any `-j' to make. Change 6e5774d84e7e3b68736f95fae09a084bd5b9ac7a made the problem much less likely to occur, but in a debug_and_release build, debug and release would share the same mocinclude.tmp. Therefore, if exceptionally unlucky, the bug could still arise. Put mocinclude.tmp under MOC_DIR so each exclusive build has its own. Reviewed-by: Lincoln Ramsay
* Fixes compile of WebKit with MinGW when using any `-j' option to buildRohan McGovern2009-04-131-23/+39
| | | | | | | | | | | | | | | | | | | | in parallel. On Windows, when a project has a lot of INCLUDEPATHs, some extra logic takes place to work around an issue of large command lines. Instead of passing all the paths directly to moc.exe, the paths are written to mocinclude.tmp which is then read from by moc.exe. Prior to this change, every moc rule tries to write to mocinclude.tmp. When running make with -j, this will happen in parallel, causing this error message: "The process cannot access the file because it is being used by another process" Change the logic so mocinclude.tmp is generated by its own rule. Reviewed-by: Lincoln Ramsay
* make shadow builds with default moc/ui dirs work againOswald Buddenhagen2009-04-073-0/+15
| | | | | | | | | | | | | | | append the source dir to the include path, but only after the dirs with the generated files. this seems to have worked before only accidentally: the unqualified default dirs were expanded to the source dir instead of the build dir, but the build dir is added implicitly by default, so things magically worked. now that we qualify the moc/ui dirs, projects relying on the strange side effect suddenly break. we should probably add the source dir to the include path by default, but this coupling to uic/moc is closer to the historical behavior and thus should be safer. Reviewed-by: mariusSO
* some more quoting for qmake ...Oswald Buddenhagen2009-04-022-2/+2
| | | | sometimes, even two reviews are not enough ...
* re-apply improved version of 3aff9113a9702ea6f7e099a73136a718ae1b992fOswald Buddenhagen2009-04-022-2/+8
| | | | | | | this time, it can deal with directories which are absolute to start with. Reviewed-by: mariusSO
* Revert "don't include uic in non-gui configurations"Rohan McGovern2009-03-301-3/+0
| | | | | | | | | | | | | | This reverts commit 7d2c8eb99c563b4fb236fe538123255f52f293a2. This commit was not reviewed and breaks compile of QtNetwork on win32 with this error... src\network\kernel\qauthenticator.cpp(55) : fatal error C1083: Cannot open include file: '../3rdparty/des/des.cpp': No such file or directory ... because the generated Makefile no longer contains src/network as an include path.
* Revert "make shadow builds work even if a non-shadow build is present"Bradley T. Hughes2009-03-272-2/+2
| | | | This reverts commit 3aff9113a9702ea6f7e099a73136a718ae1b992f.
* don't include uic in non-gui configurationsOswald Buddenhagen2009-03-271-0/+3
| | | | | | | | | uic is set in default_pre. this leads to useless -I compiler flags when no ui files are used in fact, so it would be nice to get rid of it in cases where it is not used. for backwards compat, don't remove it from the _pre, but add some magic to _post to remove it again if QT does not contain gui. of course, we need a force_uic CONFIG to enable an exception for QtGui itself ...
* make shadow builds work even if a non-shadow build is presentOswald Buddenhagen2009-03-272-2/+2
|
* Long live Qt 4.5!Lars Knoll2009-03-23321-0/+18817