Right now, the sublib targets, if any, show up between clean and
distclean targets. That's silly.
I doubt anyone is using sublib targets anyway, but...
Change-Id: I2beffc69f68fa7626ff4aa4a7cc1169b2c6c69a7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
- thread was duplicated
- x86 & ppc are obsolete and don't actually do anything
- incremental was just plain nonsense (it does something entirely
different, and it's better to hide this "feature" from public view)
- resources is basically an implementation detail (it's on by default if
qtcore is used)
Change-Id: I9163af6e8db7988382ccf993d4be280f7faec1f2
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
while the dependencies in the manual projects are crappy anyway, it is
still worth to cover the case of the user changing the install paths.
Change-Id: I0a7ca5c8ba660c689d6d7af6b65d878390d6456f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Done-with: Leena Miettinen <riitta-leena.miettinen@digia.com>
Change-Id: I1e031402bc3d857cf29782957e5340e3c82f1ed2
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
This is the first step in implementing an in-place conversion of QString
to QByteArray. This requires ref-qualifiers in member functions so we
know that we have an rvalue QString.
Converting from UTF-16 to Latin1 always requires half the memory.
For conversion from UTF-16 to UTF-8, the typical string will also need
the same memory or less: characters from U+0000 to U+007F consume one
fewer byte; characters from U+0080 to U+07FF and from U+10000 to
U+1FFFFF occupy the same space in UTF-8 and UTF-16; it's only the ones
from U+0800 to U+FFFF that consume more space in the UTF-8 string.
For the locale's 8-bit codec, we can't be sure and the code (currently)
needs to go through QTextCodec anyway.
This requires a #define set before #include'ing "qstring.h". However,
since qstring.h is included by the QtCore PCH, we need an extra qmake
compiler without the PCH flags to compile this .cpp.
After this change, the distribution of calls in QtCore, Network, Gui,
and Widgets is as follows:
const & &&
toUtf8 31 (74%) 11 (26%)
toLatin1 79 (77%) 24 (23%)
toLocal8Bit 26 (16%) 138 (84%)
Change-Id: Idd96f9ddb51b989bc59f6da50054dd10c953dd4f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The default values for PCH, the -ZW switch, and CharacterSet aren't
ideal for WinRT projects, so adjust these accordingly.
Task-number: QTBUG-35328
Change-Id: I78021d0785fa84e15b1f17264daa599a9418f92e
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the respective code was removed in 375edf7
Change-Id: Ie31ef4bc8970b5396f50f1c4963f378df816242a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
it's bogus in the first place that the meta files contain windows paths,
but straightening that out is a prohibitive effort. so instead generate
additional s/// commands which take care of these paths.
fwiw, the generated s///i command is a gnu extension. but as we are
doing this on windows only where we are using our built-in sed command
anyway, this should be fine.
Task-number: QTBUG-33794
Change-Id: I46fcc598db12816ee56b5371ab184f6277eb3a22
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Otherwise the 'Wrapper' destination of the PBXCopyFilesBuildPhase
will be empty, and the files end up outside of the application
bundle.
Task-number: QTBUG-34457
Change-Id: I799db28185a6c5d3d940602914fd8ba14c538bf2
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Link to "Getting started with qmake" was invalid
Task-number: QTBUG-34749
Change-Id: I782dc99f5182f2fe7661377eb82f35ebb50a46cf
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
let the compiler use qmake.pdb, as the linker will.
Change-Id: Ifafdfeff5a7d0ea91d796f76fbdc018c87cf8b78
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this avoids the nasty and conflicting vcXX0.pdb files in the build dirs.
VS will already do that.
Change-Id: I7bddaecf3f478edc78cd6654b5a1038db4fe04ff
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
that means further detaching the generation and installation of debug
info from the thing calling itself A Debug Build.
Task-number: QTBUG-32412
Change-Id: I4d79d1ae4806c8e4a2d6a7ccd030fb88385dd7d4
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the restriction to dlls is entirely unjustified.
Change-Id: Ia518dd16189572dea9e8f4280c88801b1393694e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this option suppresses the installation of target (leaving only
dlltarget). however, it still installed target's pdb file.
Change-Id: Ia686a647c101ca66e74944d23171e120fc74515a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
QString::replace() has no way of escaping capture group references,
so simply disarm double backslashes. of course this is broken, but
we'd need to reimplement it from scratch to fix it properly. "corner
case" ...
Change-Id: I357fbfd22c9c4a68809e5af6efad1de3a95706b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
In XCode only the pro file was shown in the Supporting Files group as
it was the first one in the list. The others were not shown as it was
recreating the temporary QStringList each time instead of appending to
it.
Change-Id: Ifbc40a25156cf639eaa34b410f534726c41b6232
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
In particular this triggers in some cases of package building
where we are using a Qt version which for some reason has
forward slashes in its install prefix. Any mkdir command
run with this Qt build will fail because only backslashes are
recognized as path separators.
Task-number: QTBUG-34886
Change-Id: I2f957c6d348852ec555a67a35ae39921523b7b3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Starting with MSVC2013, a separate set of libs for Windows Store apps is
supplied, so make sure it is in the LIBPATH (and before the desktop libs).
Change-Id: I74f3f385c2db749010fbfe7e2d4c3d1228e4e603
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
unlike .qmake.cache & co., the presence of this file has no magic
effects on where mkspecs, modules and other things are searched.
as the obvious name "cache" is of course already taken, we call it
"stash".
the file is searched up to the super cache (if present), otherwise up to
the normal cache/conf (if present), otherwise up to the root.
if it's not found, it is created next to the super cache (if present),
otherwise next to the cache/conf (if present), otherwise in the current
output directory.
note that the cache really should be created and populated by the
top-level project if there are subprojects: otherwise, if there is an
"anchor" (super/cache/conf), subprojects would race for updating the
cache and make a mess. without an "anchor", each subproject would just
create its own cache, kind of defeating its purpose. this is no
different from the existing "cache", but it's worth mentioning that
removing the "anchoring" function does not remove the "nesting order"
constraint.
Task-number: QTBUG-31340
Change-Id: I786d40cef40d14582a0dd4a9407863001bec4c98
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
otherwise, if the output dir is the root, the path would be denormalized.
the code for finding existing files already does that.
Change-Id: I56d70477e9c9ffcd936325068624a84df10ffd87
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
In 5.2, the HTML output is in a flatter structure and when they are
hosted in qt-project.org/doc, the documentation will be found at
http://qt-project.org/doc/qt-$QT_VER
The url variable is used by projects outside of Qt 5 which need
to link to Qt 5 documentation, such as Qt Creator.
Task-number: QTBUG-34584
Change-Id: Ifa55fcd9e402b0e184a41e316340e46aeb7101de
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
there is no point in setting the variables already when peeking into
the caches, as that is done in a separate evaluator anyway.
it also makes no sense to have them set while loading the spec itself,
as it's not permitted to do anything with the caches.
so set them at the next convenient point, which is right before actually
loading the caches.
Change-Id: I3717ddf94353dc04e12c52e542f16ed27b578e14
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Warn the user if QMAKE_INFO_PLIST is set, but file not found.
An iOS application will not run or deploy without an
Info.plist present, and the error message given by
xcodebuild is not very informative.
Change-Id: I54f0e06de320a43c9f3261fe88761c41e3ccd022
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
On machines where multiple versions of VS are installed, the VS version
for the vc(x)proj generator is selected by the entries in the PATH
variable. The first VS installation that's found in PATH is used.
The former logic printed a warning if multiple VS installations were in
PATH and also fell back to the lowest version if a VS version was
registered with multiple install paths.
That's the case for VC 2012 express and prevented its usage.
Task-number: QTBUG-34357
Change-Id: Ia5c66a1aea0c40e4b7460b3aa6c7daee6673da44
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
