When the UISupportedInterfaceOrientations key is missing, iOS will start
up the application in the orientation defined by UIInterfaceOrientation,
and if that key is also missing, it will default to portrait orientation.
Unfortunately, when the application has finished launching on an iPad,
there is no way to re-evaluate the current device orientation unless the
user actively rotates the device, so for example if the device is physically
in landscape orientation, and the application is started up in portrait,
the application will not auto-rotate to landscape after starting up.
It would seem that [UIViewController attemptRotationToDeviceOrientation]
would be the right API to do this, but even after telling the device
to beginGeneratingDeviceOrientationNotifications the device orientation
will still match the startup orientation until the device is physically
rotated. For iPod/iPhones this is not an issue, as the OS will update
the device orientation after startup. Presumably the difference in
behavior between the two device classes is due to the iPad supporting
any orientation for the application grid.
Since we would prefer the application to either start up in the right
orientation directly, or at least rotate to it after startup, and the
latter can't be done, we apply UIInterfaceOrientationMaskAll to the
Info.plist file. This also has the benefit that the application will
show any splash screens in the right orientation.
Change-Id: If0421bc7b82b7f14a510fa1f34eac4f6407f570f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
with qmake now de-duplicating the paths properly, we should version
these QMAKE_BUNDLE_DATA entries as well, so we don't depend on the
symlinking of the regular headers being done first.
Change-Id: Idaa2ccc1ba9b5684b0c8d84f7f760735f54432e1
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Add @FULL_VERSION@ -> Qt version substitution to
unixmake2.
This makes the Qt-generated Info.plist files compliant
with the bundle signing/validation process.
Task-number: QTBUG-32896
Change-Id: I1818f028c2f740d699629dd78cc0fe6ffaf94a1c
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
We do so by setting a 'no_plist' config property. Can be overridden
with 'force_debug_plist'.
The debug version of Info.plist would overwrite the release version,
and it also happens to contain invalid data. In particular,
CFBundleExecutable would contain the _debug suffixed libname, which
it shouldn't. See the entry about CFBundleExecutable on
https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
Task-number: QTBUG-32894
Change-Id: Ideb018e4768a7c4e276e1b07d77937451f6db6a2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
avoids that we needlessly initialize QMLIMPORTSCANNER in addition to
QMLIMPORTSCANNER_SYS (by making the former have the contents of the
latter).
Change-Id: Ib8a12975de426ae94bd78d489099157c94cea189
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
to this end, add a mode to qtPrepareTool() which prepares the primary
variable for system() use (instead of use in makefiles).
Task-number: QTBUG-41032
Change-Id: If6aa6c206a70ecdbc2ea05bbb3cb470414fb02b1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
MinGW static libs use libfoo.a format, and not foo.lib.
Change-Id: I899adca8ec0b1c8430f5b6c4f18ad0ea1dc6d398
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Giving instructions, rather than forcing one to grep qtbase for the error
message is always a good thing.
Change-Id: I0f5abed341368cdf817dc0110c2c250b377a30de
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This field specifies whether the app is an iOS app.
Change-Id: I38cfcbec97b32f517a14a9a34f1eb871b9fa1ef7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
the condition is copied 1:1 from the BUNDLE_DATA logic in qt_module.prf.
Task-number: QTBUG-41267
Change-Id: Ia80a9a29319f70017e090855cf8d35a77b9e727f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This follows the discussion at:
http://lists.qt-project.org/pipermail/development/2014-June/017225.html
Qt WebEngine will have a version of 1.0 when released with Qt 5.4.
The library name is currently libQt1WebEngine.so.1.0.0 but it should
rather be libQt5WebEngine.so.1.0.0 to represent Qt's major version
releases as a whole and not the major version of the module. This
prefix essentially expresses the module's dynamic linking
compatibility with other Qt modules.
This only makes sense if each major module release will be compatible
with a single Qt major version only.
All published modules currently already have 5 as their major version,
except qtenginio which doesn't use a Qt prefix, so this change has no
effect except for qtwebengine.
Task-number: QTBUG-30910
Change-Id: I894e7a367624c7fc263cf08104173a82eafd1439
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
X11 and the GL libraries are installed into /usr/local like other
software, and this has been the case for many years.
Change-Id: Ied4d9d61154014db3861bdbd6a5bdbe68e76f878
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Follow-up to 9de2853a ("Remove automated generation of dwarf index"):
gdb_dwarf_index.prf does not exist anymore, so stop referencing it.
Change-Id: I22464d5b81a50a2f58218d74a424f3a790aa1df0
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Device specific compiler flags need to go to QMAKE_CFLAGS, so that
they are used also when --force-debug-info is used. Removed separate
_DEBUG and _RELEASE, since the gcc-base provides same defaults.
Change-Id: I6ce0133a1acf419261b7756525185f43581d2a9c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This is done by defining QMAKE_LFLAGS_RPATH for compilers for Apple platform.
Task-number: QTBUG-31814
Change-Id: I9040df341ad46395d6ab71bc760ba7a5ee5ff291
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
We no longer support the maemo/meego platform, so we can remove the
specific code for that platform.
Change-Id: Ia7f0730eba2d96794b97b7ca4753f63a2d7bc2a8
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
This code hasn't been tested for at least 4 years. It's not maintained
and probably doesn't work.
Change-Id: I4b9a5179e34111b400914f91caa6b741b69771bb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
When deploying QML applications, the androiddeployqt tool can
use qmlimportscanner to detect the QML dependencies of the
application, but then it needs to know the root of the project
as well as additional QML import paths. We use the already-existing
QML_IMPORT_PATH for the import paths, and default to using the
location of the .pro file for the root path (same as for static
builds in qt.prf).
Change-Id: Ib536272ed1f3f1320ea8ef529655e2ba003bc734
Task-number: QTBUG-34175
Reviewed-by: BogDan Vatra <bogdan@kde.org>
It's needed by androiddeployqt tool to run "zipalign" tool
and to set it to gradle properties.
Task-number:QTBUG-40481
Change-Id: I3dd665a7461a4e981867cdad75a50940e46a5ae6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Now that we rely on simd.prf for all SIMD sources (including NEON and SSE2),
we need to ensure that CONFIG has the right SIMD values to match simulator.
This worked before due to us checking QT_CPU_FEATURES.$$QT_ARCH and adding
directly to SOURCES.
Change-Id: I4ea7f559e83860eabff1948ad5d140bbb65454df
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
when doing a module-by-module build, we need to also use includes and
libraries from the install tree, as it contains the current module's
dependencies. but a pre-existing installation of the current module must
not be found first, as it would cause trouble latest when it was somehow
incompatible.
but purely topological sorting of the dependencies could cause the
locations to be mixed up. therefore we give modules which are part of
the current build a priority boost.
Change-Id: I8fdbb46f0a2a630781c8a2177468039c1122151a
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
For multi-pass RCC qmake generates broken VS project files, because
the RCC extra compiler directly calls the C++ compiler on a generated
source file. Adding this call to a VS project file will bypass any
project settings. Also, the VS project generator is not prepared to
add extra compilers that generate object files.
Task-number: QTBUG-39685
Change-Id: I1bcaad8936be8371d596f29ed8952888ba95f7b2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This was a long-time coming.
One innovation from this commit is that it will add the source to
SOURCES if the compiler is already generating code for that specific
target. That is currently always the case for Neon, and the MIPS DSPs
since that is the only condition in which configure will enable those
targets. And because of qt_module.prf, it's also always the case for
SSE2 (but not for SSE3 or higher).
So simplify the .pri files by removing always-true conditions.
Change-Id: Ib24af74717b652c9a6be246e3c17a839470f37da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
We don't actually detect whether the compiler can create Neon code or
provides Neon intrinsics. Most of them do, so that test would be mostly
moot. We removed the detection previously because we couldn't
automatically enable Neon due to leakage of instructions outside the
areas protected at runtime.
Instead, we rely on the mkspec properly passing the necessary flags that
enable Neon support.
This commit does not change that. All it does is verify whether the arch
detection found "neon" as part of the target CPU features. In other
words, it moves the test that was in simd.prf to configure.
It does fix the Neon detection in configure.exe, which was always
failing for trying to run a test that didn't exist
(config.tests/unix/neon).
Change-Id: Id561dfb2db7d3dca7b8c29afef63181693bdc0aa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This patch adds the feature use_gold_linker to use the gold linker that
has been part of of GNU binutils since 2008. Gold links C++ libraries
much faster and use less memory.
The feature is autodetected when building Qt on Linux, but can be disabled
in configure. On MingW builds it is default off but can be enabled for
cross builds.
Change-Id: Icdd6ba2e706b2c791bcf44b6e718c2b7a5eb2218
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We don't have a way to rename main() inside a LLVM bit-code file yet, so we
error out if we detect that LTO is enabled (which causes object files to be
written as LLVM bit-code), and inform the user about a workaround.
Task-number: QTBUG-40184
Change-Id: I89c927a3a7f075c65e54442c4f7e6bb25175b6f7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
GCC currently requires fat object files for static libraries, since the
linker would otherwise not load the .o file from the archive at all and
the linking would fail with a lot of undefined references. Clang on
Linux also needs this, but it has no equivalent flag, so enabling LTCG
for Clang on static libraries will result in linker error.
This commit does not add support for enabling it in configure. It can be
enabled on a per-project basis by doing CONFIG += ltcg or by passing
-config ltcg to qmake's command-line.
Change-Id: I52cf99f1ed9f1701e23a3b457ba3502fd28126ce
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
currently there isn't a clean solution yet to support object files
or architecture specific files during the preprocess step when
using the xcode generator.
This fixes ios resources (but will break with large resources).
Task-number: QTBUG-39835
Change-Id: If620ab0c3b5c1f92db8f7b4740061c807730db57
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Most compilers out in the wild still don't support the flag, so we need
to compare the version number anyway. This also makes it ready for
whenever compilers start supporting -std=c++14, something we should fix
for C++11 too.
It overrides the CXX11 variable for two reasons:
1) we reuse the mechanics in c++11.prf
2) we avoid c++11.prf overriding the flag if qmake decides to process
it later (CONFIG += c++14 is additive)
Change-Id: I79b6523fd9017483f2474634d1c09f2fd5ea039d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
We have to escape the target name to avoid compilation errors.
This fixes the compilation failure in the qprocess autotest.
[ChangeLog][Android] Added support for building libraries with
spaces in name.
Change-Id: Ib98ba261fb3a4cc1e835d0cd2f93aac6855a7c21
Reviewed-by: BogDan Vatra <bogdan@kde.org>
MSVC 2013 implements the behavior mandated by C++11 that removes the
ability to downconvert a string literal to a modifiable char*, but it's
not enabled by default. This option turns it on.
It's only enabled for release builds because the compiler page has a note
saying the Standard Library has bugs that prevent it from working in
debug mode. See http://msdn.microsoft.com/en-us/library/dn449508.aspx
Visual Studio "14" has this fixed.
[ChangeLog][Compiler Specific Changes] Release builds with Microsoft
Visual Studio 2013 now enable the standard-conforming C and C++ strict
string behavior. This option will be enabled in all builds with future
Visual Studio versions. Non-conforming code should be fixed for maximum
portability and correctness. See
http://msdn.microsoft.com/en-us/library/dn449508.aspx for more
information.
Change-Id: If5ba6cc8456209b268e047d1010710fe332b8312
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The integrated assembler of clang does not understand some/all of the
ARM macro assembler syntax used in pixman-arm-neon-asm.S. By default,
this integrated assembler is used when using the "clang" command as a
driver. This patch turns off the integrated assembler of clang for that
file.
Change-Id: Ic06801266b5a4b097ca835d815bcc5d5fc672946
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When LTCG/LTO is enabled, the link-time compilation will not use the
data in the object file, but instead the precompiled data in a separate
section, which is still blank and may not be recognizable by rcc's
second pass. That would result in all resource data being nulls -- and
the best case scenario out of that is that QResource concludes that
there is no resource (it could be worse).
That happens with GCC 4.8's GIMPLE intermediate format: a fat .o file
containing GIMPLE would be modified by rcc but GCC would not use the
modified data at the link stage, whereas a non-fat .o file would not be
recognized at all by rcc and the compilation would abort.
Change-Id: I78ccbfd77ceaa723f22a4f82b5b4d6536a80d65d
Reviewed-by: hjk <hjk121@nokiamail.com>
Unlike MSVC, ICC is capable of selecting each of the processor feature
levels, so let's define the right macros.
Version 9.1 is really old and not supported, so we don't need to keep
the old workaround.
The compiler has been complaining that option -GX is deprecated and will
be removed, so update it to use the same as MSVC does.
Change-Id: I4158fcf2331c1d27462bb1cb19725c7136efab4a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
mkspecs/qnx-x86-qcc/qplatformdefs.h
src/corelib/global/qglobal.h
src/network/socket/qnativesocketengine_winrt.cpp
src/plugins/platforms/android/androidjniaccessibility.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
Manually adjusted:
mkspecs/qnx-armle-v7-qcc/qplatformdefs.h
to include 9ce697f2d5
Thanks goes to Sergio for the qnx mkspecs adjustments.
Change-Id: I53b1fd6bc5bc884e5ee2c2b84975f58171a1cb8e
This is essentially an opt-out using CONFIG += resources_small for the
'big-data' feature introduced and made mandatory with commit 5395180.
This is currently not active in any configuration, but can be used
when the two-pass approach is neither needed nor wanted.
Change-Id: I6d4f663843e629da6f39ac4da5e77d39c58b3ddf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ICC does support C++11, but the Apple headers contain invalid code that
Clang seems to accept. In C++11 mode, code using CF_ENUM expands to:
typedef enum EnumName : CFIndex EnumName; enum EnumName {
Which is valid Objective C++, but not valid C++.
Bug reports to Intel and to Apple are pending.
Discussed-on: https://groups.google.com/a/isocpp.org/d/msg/std-discussion/yDfkDo6C0BM/EVWzwjVbyh4J
Change-Id: I7d501e94212a90f5c7197a3b56016dadac2c44ad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It somehow forgets the dot and thus can't open any moc or uic includes.
Intel bug: DPD200357915
Change-Id: I610ba4d3df0072bfb83f90347d94f4586d0d8c86
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Intel compiler does support C++11 options on the command-line.
configure.exe will correctly try to run it, but the test would fail for
incorrect reasons.
First, we need to pass the option -Qstd=c++11 to enable it.
Second, on Windows, the GCC experimental define isn't defined, nor is
__cplusplus updated yet. So we have to rely on the Intel-specific macro.
Third, we need CONFIG += console so that the application succeeds in
linking against a main() function, as opposed to a WinMain one.
Change-Id: I8f3252189df4f8854a9d9aa2cd919c288d2df420
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The -xXXXX options are deprecated, so use the GCC-style -mXXX options.
Change-Id: I235c73c4a170003b5b5e20bd4c4c7125107f7f82
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
x86 doesn't care about alignment, and on all other platforms where it
does something it causes build errors, so instead of removing it on
those platforms just don't enable it at all.
Change-Id: Idfeb387099b28af60ba161b6ca678b7c9df17fe1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Revert cb09e1e889 for MinGW. gcc on Windows reproducably crashes
when the pre-compiled header becomes big enough ...
Change-Id: Icd5a3dfbe59f5ff5c78832e7b4436d0f1cfa1031
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
For static builds of Qt Quick apps, qmake generates a qml_plugin_import.cpp
file. Just like the Makefiles, it should be removed only for distclean,
not in the clean step. This is what we do for non-qml plugins, too.
Change-Id: I5a3f2e7d27c3ffd5161162a8a03e4dd9c9245af5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Webkit has a different layout, so allow the tests to be found in
the appropriate location.
Change-Id: Iedbea6daada98a3c3efdbcfc1fe4df5d2c8cea6a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Private qtwayland headers were not installed at first build, since
qmake was ignoring unexisting files from the install target. It
required another run of qmake to have a proper Makefile generated.
The rules for generated headers need CONFIG = no_check_exist, so that
files get listed in the Makefile even if they do not exist yet (thanks
to Loïc Yhuel for the pointer).
Change-Id: I1a0278d629295a55a3ddcf5f8fb068a04ba5be47
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
When qtbase has been compiled with PCH and trying to compile the
disassembler in QtDeclarative creating the PCH for "C" is failing
due the C++ includes. Guard the includes with __cplusplus to be
"usable" on C code. This guard is proposed for the "stable.h" in
the qmake precompiledheaders documentation.
Change-Id: I7a8fb9e59c666a2e1535d988fd71c5cd67d0587d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the no_dll switch has questionable semantics: it pro-actively breaks
non-dll builds. therefore its usage needs to be limited to dll build.
Task-number: QTBUG-39594
Change-Id: I98328e502693df835af565b5ec25ada2c1c168ad
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Traditionally, RCC in "C mode" was meant to bundle small resources into
a binary, like help texts or an occasional icon. RCC produces a .cpp
file containing the actual data in a char array which is then passed
to the compiler and linker as a normal source file. Larger resources
should be compiled in RCC's binary mode and loaded at run time.
Current Qt Quick use tries to deploy large hunks of data in "C mode",
causing heavy compiler/system load.
This patch works around the issue by splitting the process into
three parts:
1. Create a C++ skeleton, as usual, but use a placeholder array
with "easily compilable" (mostly NULs) data instead.
2. Compile the skeleton file.
3. Replace the placeholder data with the real binary data.
time (qmake5 ; make clean ; make) takes 1.3 s real time for a
100 MB resource here, and there is still room for improving patching
performance if really needed.
Change-Id: I10a1645fd86a95a7d5663c89e19b05cb3b43ed1b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
QNX 6.5 does not have readdir64_r, which is selected by current
qplatformdefs.h. There is only a reentrant version (readdir_r) which
does not support large files and a large file version (readdir64) which
is not reentrant. The reentrant version (readdir_r) will be chosen now.
In summary, the following versions will be used:
QNX 6.5: readdir_r (postfix '_r': reentrant version)
QNX 6.6: _readdir_r (prefix '_' : extra stat info included)
BB 10: _readdir64_r (infix '64': large file support)
Change-Id: I00739f0e2054a32f52555309d03463a6c52e3d99
Reviewed-by: Wolfgang Bremer <wbremer@blackberry.com>
Reviewed-by: Samuli Piippo <samuli.piippo@digia.com>
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
qml2 needs QML2_IMPORT_PATH.
this didn't affect non-prefix builds (which most developers use), so
it wasn't too serious.
Change-Id: I435dca151348669b66f091f9a9324cd69394284e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
a) qmlimportscanner has no built-in -importPath, so it can't be omitted
even for non-prefix builds, and b) the QMLPATHS variable is also used
further down, so we can't just do away with it.
amends a658fa40.
Change-Id: I42a47a82fe13694fbac3c4a3962ebbe1d7e7865b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
it helps enormously to use the flag correctly.
amends f0c34eb08f.
Change-Id: I04a63cc59e133169d9f6677f2f88ef98fd5c524c
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
qdoc uses the indexes as "precompiled headers" to obtain type info
necessary to properly parse sources.
the indexes needed are the ones the module actually depends on
(publically).
Change-Id: I6aad0b511d2534d584f7947c8d800300eede94ff
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
the doc/ dirs in the build dir won't be created until the docs have been
built, so of course checking whether they are there during the qmake
phase is counterproductive.
this also means that we'll get some complaints about non-existing
directories (for repos that don't create any docs). there is no
reasonable way to query qmake which repos are affected, and writing
shell-specific code to query it at make time seems a bit overengineered.
Task-number: QTBUG-38862
Change-Id: Ie0588e75bfc39718fffd46f0df6785428e396eb2
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
even if we are not doing a top-level build, we still need to specify an
index dir. that may be the install dir or the qtbase build dir,
depending on whether we are building against an installed prefix build
or a non-prefix build (building against non-installed prefix builds
outside a top-level build is inherently impossible).
Task-number: QTBUG-35596
Change-Id: Ia37d429855480d3bfe36b7ee29e087029861bfc5
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead of adding all possible plugin paths (for which QMAKEMODULES
wouldn't have been a reliable source anyway), only add the paths of
plugins of the necessary types.
this necessitates that we create qt_plugin_<foo>.pri files also in shared
builds of qt when making a prefix build. we don't install them unless it's
a static build, though.
Change-Id: Ib56b009562a7131d4dc4dfc259b34ec6581b0f77
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Makes it possible to use "android-extra-plugins" from qmake through the
ANDROID_EXTRA_PLUGINS variable.
Change-Id: I7c67e9f104e5397e094afff730efccb91949caa2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
CRT dependencies should contain "Phone" in the name.
Change-Id: I1b0de01df6a016c20b59232f6068e9bb87e3f18c
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
a162a3cb (Android: Add "unversioned_libname" configuration, 2014-04-23)
removed the version for shared libs on Android. This change updates
the generated CMake files to support that.
Change-Id: Ia6ef04872c664bd4c31546456a82730babed2910
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
We don't use it and it was never documented. Search engine hits
only point to this occurrence in the Qt sources.
Change-Id: I2dd7adc5438893560daf01ac85620d9f9c028982
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We'll use the master depends header for the module as the precompilation
header. We could use the master include, but tests show that
precompilation benefits taper off for big precompiled headers. The
important part is to get the Standard Library headers precompiled.
Each module can still override which header to precompile by setting
PRECOMPILED_HEADER after load(qt_modules). It can also turn off
precompiled headers by setting that to empty or by CONFIG -=
precompile_header.
Testing a few build times shows the following improvements (GCC 4.8 with
-O3 and C++11):
QtPrintSupport: 14.7%
QtOpenGL: 22.7%
QtDBus: 29.5%
QtSvg: -2.4%
QtXmlPatterns: 26.1%
QtQml: 21.6%
QtQuick: 25.0%
QtMultimedia: 9.0%
QtSerialPort: -30.0%
QtHelp: 5.6%
The numbers also show that precompilation is worse for small modules.
Change-Id: I3793fafcedaff5456527cd6b3777ffd162975c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The _HAS_EXCEPTIONS=0 define that was introduced in commit
f59083636b leads to lots of C4275
warnings:
non dll-interface class "stdext::exception" used as base for dll-interface class "std::bad_cast"
from the <algorithm> include in qglobal.h.
Newer versions of MSVC do not have this problem.
Task-number: QTBUG-39126
Change-Id: Ieea5adde649fe16e6b41fbbb23fd582b3bb12b89
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
the location of the import paths have changed a long time ago.
also, we can make use of QTREPOS now.
Change-Id: Iee50854b7441968c3c60538e54d9312e53d39cb6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
now that we have QTREPOS, we can use that directly instead of collecting
the QT.<foo>.qml dirs. as a "side effect", this makes qml modules without
a corresponding c++ module available to the scan.
Change-Id: I6f172121588ec01c9fa47a99d9990bf9fcfbc69f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we need to store commands with system path separators in the .pri files,
as we might clobber windows command arguments if we just converted
separators later on. and we can actually do that, as the path separators
are actually bound to the host system, not the shell.
we also need to shell-quote the commands, as whitespace, and more
commonly windows path separators in an msys shell, would break things.
we delay this to the last moment possible, as it does depend on the
shell.
Change-Id: I1fe6b63aebd5663b72492c32928ec397f86e336f
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
The linker complains that some symbols were compiled with different visibility
settings when linking host_build tools such as the import scanner. As it turns
out, we do CONFIG += hide_symbols for static libraries (such as bootstrap or
qmldevtools) but naturally not for the final program source code. It appears
symbol visibility is not of importance for static libraries in host builds (as
opposed to static libraries later linked into shared libraries), therefore this
patch removes that.
Change-Id: I237a2d8669374eb059dc91b5378f6e3ec93d67a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
If the prefix isn't "m2" for the 2013 namespace, Visual Studio Update 2
won't open the document in the designer view. Even though there is
nothing technically wrong with the way it's currently done, change it to
"m2" to keep VS happy.
Change-Id: I62721114610de5396eb507828b39db89c1e96b1a
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Tweak qmake, add mkspecs for emulator and device, adjust the
manifest template for WP8.1, and add missing icons.
Change-Id: I7a6405fa85297ae4cc8522015274e65fb7a315a6
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
of course all helper libraries are built statically, so the criterion is
not useful. what is interesting is whether the whole qt configuration is
static, as that determines what will happen with the helper library when
linking the final "actual" artifacts.
Change-Id: I96980c645cb478b2f7a30688b49cb51bec8c9f08
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This matches the -ffunction-sections from bootstrap.pro, which tells the
compiler to create a section for each function. The -gc-sections option
tells the linker to drop what wasn't used (normally, it only drops
entire files).
Before (on Linux, built with -O3, no LTO):
text data bss dec hex filename
1746385 7920 3750 1758055 1ad367 bin/moc
1444101 6664 1894 1452659 162a73 bin/rcc
4407725 1568 4896 4414189 435aed bin/qmake
After:
text data bss dec hex filename
1131655 6520 3494 1141669 116ba5 bin/moc
1027043 5480 1766 1034289 fc831 bin/rcc
3578489 1656 5313 3585458 36b5b2 bin/qmake
Gain: 35% on moc, 28% on rcc, 19% on qmake
Before (on OS X):
__TEXT __DATA __OBJC others dec hex
1495040 12288 0 4294993008 4296500336 100176470 bin/moc
1265664 8192 0 4294983904 4296257760 10013b0e0 bin/rcc
5279744 81920 0 4297912320 4303273984 1007ec000 bin/qmake
After:
__TEXT __DATA __OBJC others dec hex
806912 8192 0 4294988132 4295803236 1000cc164 bin/moc
720896 8192 0 4294979764 4295708852 1000b50b4 bin/rcc
4841472 77824 0 4295580688 4300499984 100546c10 bin/qmake
Gain: 46% on moc, 43% on rcc, 8% on qmake.
Change-Id: Icc7cdc9fd6f5db15537b4adabaac7e7a27e539d4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Move it from bootstrap.pro into qt_module.prf so it will apply to any
other bootstrapped libraries, like libQmlDevTools.
Variable called "SPLIT_SECTIONS" because -fdata-sections could be added
in the future, if it proves to be a benefit.
Change-Id: I3fbb004f111620a84e58e9112e9bce3afd95631e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
we can't derive the doc index paths from QMAKEMODULES, as the mkspecs dir
may not live at the repo's top level.
instead, explicitly announce the repo's top level build dirs in QTREPOS,
and use that accordingly.
Task-number: QTBUG-38862
Change-Id: I643ad2bf63c8fca0ffc44ce3457dbe8a16dcab07
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Matches the compiler capabilities better and will catch all GCC-like
compilers (including Clang, LLVM and Intel CC on Unix).
Task-number: QTBUG-38544
Change-Id: I102966d307a4e167b6dcf3da08359e656f3af45e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
