Naming for different logo sizes on WinRT has been varying in the
past and evolved from using small/medium/large to some being
explicit (71x71).
Add new values introduced by 8.1 (310x150, 310x310,...) and clean up
mixed usage. Detailed pixel versions overrule general specification
and latter ones stay mostly for compatibility reasons. Still the
preferred way is to use explicit pixel values.
Task-number: QTBUG-43644
Change-Id: I9173ec2951a82e5eac9d8c9956bfb0bb4d1a2459
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
By using the special "ar" and "ranlib" tools, the symbol table is made
visible, so we don't need fat LTO binaries. Since we need to store the
new tool names, we may as well clean up ltcg.prf with variable names for
the fat mode too.
Change-Id: I7e53af0c74a3d069313f38500b72538af1d61128
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Instead of trying to load in ltcg.prf and cache the value.
Change-Id: If485ff68fc6ff9d9cf7009cd72d5e702d0199c7f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Currently you could only invoke windeployqt for debug and release
builds, but not windeployqt_clean resulting in artifacts after
the clean step.
Change-Id: I3a93e4909a017f3594cc5b0c2249ed25b777c008
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Andrew Knight <qt@panimo.net>
Glibc will use the intrinsics for 32- and 64-bit, but didn't for 16-bit
(probably because GCC didn't document it until version 4.8), so this
commit will make us access the intrinsics directly the intrisincs for
all type sizes.
Additionally, this will get us access to the compiler intrisics even
without Glibc, such as when building against uclibc or Bionic.
Another benefit is that both Clang and ICC will use the MOVBE
instruction on Atom and Haswell architectures.
Change-Id: I39d1891f479887d719d69ebe4ac92ac9bfeda8af
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Since QtWebKit started using stabs on some platforms to reducing
memory pressure during linking, the tricks to strip out debug-info
in the internals no longer worked because no-debug-info doesn't strip
the -gstabs compiler and linker flags.
Change-Id: I151088f29058b8fe50cba9aa3ec8ecd84b85d7d8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Whenever a binary is created and linked against a static lib that was
compiled with LTCG, the final linking step requires the compiler flags
so that the pre-compiled data in the shared library can get properly
compiled.
This could happen for a static build of Qt with LTCG, but also happens
frequently for Qt's own build when linking regular libraries and
applications against QtBootstrap or QtPlatformSupport. The linking fails
when the target is a shared library (example: QtWaylandClient linking
against QtPlatformSupport).
The .prl file actually contains the "ltcg" flag, so the best solution
would actually be to process that flag there and add link_ltcg if any
dependent .prl has "ltcg", but I couldn't find out how to do that.
Change-Id: I4a75a14d1dcb8c2089a427285e25d5555df7d7d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Combining them could lead to intermediate builds having cached the
path, but not the version, resulting in later version checks failing.
Change-Id: Ia10f4268ce7b9e82c81627970236d68c00b80391
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
This sets the prefix for frameworks to "org.qt-project".
Applications keep using the default Xcode preferences
prefix.
Task-number: QTBUG-32896
Change-Id: I67384f643888f2de3dd8e36b9bce0f04ca4e16dd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The change was made too late in the 5.4.0 release
cycle, and broke the Qt build and deployment in
several areas:
- macdeployqt
- OS X 10.7 builds
- shadow builds
This reverts commit c0a54efc40.
Change-Id: I1c1ad4901228f5516352ccdfa963e8ea2b5013b6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
This makes the 'big-data' feature introduced and made mandatory with
commit 5395180 opt-in trough CONFIG += resources_big.
Since the feature has been introduced several setups have been
found where the feature cannot be used, or not be used out-of-the-box.
Using the traditional default behavior lowers the risk of further
breakages.
Change-Id: Ifd04204adadeec539e962d6a9a6955f63781bd36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Ensure the sdk is of recent enough version since:
1. we build Qt with the latest sdk version, so the app needs
to do the same to avoid compatibility problems e.g when linking.
2. using a launch screen to support iphone6 depends on sdk 8
3. Apple requires apps that are pushed to appstore to use the
latest version of the sdk.
Ideally we should store the sdk version used to build Qt, and
require that apps use the same version or newer. But this patch
will do until that is in place.
Change-Id: I18b06d09c1eda15122975b7169ca7a3372df6054
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Add WINRT_MANIFEST.rotation_preference as description which orientation
is allowed or preferred by the app. Valid values for Windows Phone are
portrait, landscape, landscapeFlipped. WinRT also allows portraitFlipped
Task-number: QTBUG-40830
Change-Id: I6b11afcdb72c2c158dadddafc5d90c1d18ab9d8b
Reviewed-by: Andrew Knight <andrew.knight@theqtcompany.com>
Defaulting to absolute_library_soname on configure -rpath is no longer
necessary as now we support @rpath install name ids on OS X and iOS.
This also sets QMAKE_SONAME_PREFIX to @rpath for Qt modules when built with
rpath configuration.
This makes Qt libraries relocatable on OS X. Qt SDK is not yet relocatable
though, because plugin location (including cocoa plugin) is still resolved
using absolute path (see QTBUG-14150), also there are several absolute paths
hardcoded in qmake mkspecs pri files.
Task-number: QTBUG-31814
Change-Id: Ie9dffefcd2a946c1580293d433621c1adb7e06c4
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
This is triggered only when app is using Qt and Qt was built with "rpath"
configuration and project does not specify QMAKE_RPATHDIR explicitly.
Added rpath is made relative to app binary location if target path lies inside
Qt SDK, so all SDK bundled tools and examples will work automatically without
any changes. Tests are an exception here, since they are being run from their
build location by CI, we may not use relative rpath that work only in install
location.
Task-number: QTBUG-31814
Change-Id: I3690f29d2b5396a19c1dbc92ad05e6c028f8515b
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Tested with GCC 4.9, Clang from XCode 5.1 and ICC 15 beta.
Clang 3.5 (pre-release) cannot compile qtdeclarative yet with -Werror
due to invalid C++ code there that calls member functions on null
pointers.
Change-Id: Ic2845371a1899716985bc0813dfb820fa418e207
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
when a module delegates to another module (as the activeqt ones do), it
doesn't have a master header to be included. we could derive the real
master header by doing a transitive dependency resolution and some
filtering, but that seems unnecessarily complex.
Task-number: QTBUG-41892
Change-Id: Ie7ce51a837ac06e929b204ec734206c11b3ae241
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
... to avoid that inherited MAKEFLAGS turn out to be incompatible with
the make we choose.
Task-number: QTBUG-39527
Change-Id: I47d4cec58b0643cc5d97868e70b24f7f37e964bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This reverts f0ee55c00. VERSION actually makes sense on Windows,
because it embeds a VERSIONINFO resource into the DLL that can
be inspected by the user.
Task-number: QTBUG-37961
Change-Id: I6b81b5aa999eba16cb8d9a4d61bd596310af46b9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Since commit cd1dff75, we use QMAKE_LFLAGS_CONSOLE when linking DLLs that
are built with CONFIG+=console. Thus, we must not pass options that are
specific to linking executables.
[ChangeLog][qmake] WinCE makespecs must not add /ENTRY: to
QMAKE_LFLAGS_CONSOLE and more. The flag is hard-coded in console.prf now.
This is a side effect of making it possible to specify a subsystem for
DLLs.
Change-Id: Ib481fd45b12140f9f05bf123db7152a3ddf0fa04
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Pass QMAKE_LFLAGS_WINDOWS and QMAKE_LFLAGS_CONSOLE to QMAKE_FLAGS
regardless of the project template.
The /SUBSYSTEM linker switch is not exclusively meant for executables
but can also be applied when linking dynamic libraries.
This is needed when building DLLs for Windows XP with VS >= 2012.
Task-number: QTBUG-41504
Change-Id: I5966cba1b6756e15275fa5d7fdbc42b99c95c07b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
GCC and Clang support compiler intrinsic error detections tools:
address, memory, thread, undefined
Let users conveniently enable it in qmake, for instance with
CONFIG += sanitizer sanitize_address
Also add a -sanitize [...] option to configure to use it by default
for both the Qt libraries, and user applications.
[ChangeLog][configure] Added support for GCC/Clang -fsanitize= options
Change-Id: Ie5418abcdf41842566df510d7707e41739e66f87
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
"system" refers to the system's native shell, which is what qmake's
system() invokes, and whose convention by far most commands invoked from
a makefile will need.
"shell" refers to the shell invoked by make, which diverges from the
system shell only when qmake/mingw32-make is called from an msys shell.
its conventions need to be used for anything the shell itself does
(e.g., assembling env variables, but also command line argument
unquoting) and the commands the mkspec sets according to the shell
(e.g., QMAKE_MOVE).
Change-Id: I0000aa9417c199cf8a810619d31ded24bb0675f9
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
at some point we stopped adding the qtmain's library path before its
respective -l flag, which lead to qmake being unable to resolve the
library location and thus ignoring its prl file.
Change-Id: I390a31f8ac2877d3823dfd2787b2cc8c696b0ec0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This allows the developer to provide a list of languages to the manifest
by listing them in WINRT_MANIFEST.languages. It also allows setting the
default language with WINRT_MANIFEST.default_language.
Task-number: QTBUG-38557
Change-Id: I5cb94c9f45146e3068d0833b9e669dc17dca14b2
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
we don't link static libs into other static libs, so the intermediate
libs need to be installed and resolved at app link time.
Task-number: QTBUG-32519
Change-Id: I0558140f98a6938b03306df7f800d66f8a19a7cd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jeremy Lainé <jeremy.laine@m4x.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this covers convenience libraries which are linked into dlls (if we are
not building statically) and "proper" (installed) builds of 3rdparty
code.
Change-Id: I2f00248c0baa0e73346e477724bf49bbc62ba925
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Instead of collecting all files from the "fonts" directory to deploy
them to the phone, we only collect files which are mentioned in the
FONTS variable. Otherwise fonts that were copied to the fonts directory
earlier (due to FONTS being unset (default fonts) or set to another set
of fonts) will also be deployed as part of the project.
Change-Id: I24c77e154a9f2ec75e88d487c056b0be46e17e87
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
they have been fully superseded by 4255ba40ab.
Change-Id: If7ac14c8b7d3cf00fb0cb916036b62eb86c9cee0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It has been fully obsoleted by 4255ba40ab.
This reverts commit 99eecab83d.
Change-Id: Id7b8d3bba27ff43e38e4fe32a4f2950de9ced493
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: John Layt <jlayt@kde.org>
neither .prl nor .la files even contain include paths.
in .pc files, we assign the final path to start with, so there is
nothing to replace, either.
Change-Id: I919dfa01e0a1d0ef8ef1220174de1d33c66cedf9
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The default is still DWARF instead of DWARF with dSYM for static builds
of Qt, so that debug builds of the final application don't take forever
to build due to generating the dSYM file.
Change-Id: I370d800d7c959e05c1a8780c4ebf58fff250daa1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
instead of assigning plugins to the first module which claims the whole
type, try to assign it to a module which the plugin claims to extend.
as we are getting stricter in that go, somebody needs to claim the
'generic', 'platformthemes', and 'platforminputcontexts' plugin types.
the natural claimant is QtGui. however, as we don't want to auto-link
any of these plugins, make them all claim that they extend a
non-existing module.
QtGui also claims 'iconengines' plugins.
the 'printsupport' plugins are also claimed by the respective module.
Change-Id: I7af7c16089f137b8d4a4ed93d1577bd85815c87b
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this means creating forwarding pris also for plugins.
unlike for qt modules, we don't actually populate the .PATH unless it we
are making a prefix build (and thus expecting it to be outside the
regular location).
Change-Id: Id836821cddec8d5f53d0708ae001e8eaa13cc71b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the plugins already declare which modules they belong to.
additionally, we allow plugins to declare which modules they "extend" -
e.g., while the Quick accessibility plugin belongs to Gui's 'accessiblity'
type, it makes no sense to link it unless Quick is actually linked.
finally, it is possible to manually override the plugins which are linked
for a particular type, by setting QTPLUGIN.<type> (to '-' if no plugins
of this type should be linked at all).
Task-number: QTBUG-35195
Change-Id: I8273d167a046eb3f3c1c584dc6e3798212a2fa31
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
To enable windows xp support, we must do two things:
1. linker flag must be /SUBSYSTEM:CONSOLE,5.01 or
/SUBSYSTEM:WINDOWS,5.01. For x64, the version is 5.02.
2. Do not use Windows Kit 8. Win SDK v7.1A is recommended. Prepend the
right include paths and lib paths to INCLUDE and LIB before
building.
The Windows XP target support is enabled by passing "-target xp" to
configure.
Task-number: QTBUG-29939
Change-Id: I84c8439606cc2a9d27d64947702846faa4f1e4a2
Reviewed-by: Lucas Wang <wbsecg1@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
WinRT distinguishes between regular capabilities and device
capabilities. For now the latter section are location, microphone,
proximity and webcam. Hence we must add those properly to the generated
manifest.
However, Windows Phone currently combines all of these into the
Capability section, so add a warning if someone uses devicecapabilities
for Windows Phone.
Task-number: QTBUG-37932
Change-Id: I8e9550f29b6afdea3737cc85bdc68344fc04223d
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
For Visual Studio we can add the fonts we want to deploy to the
project file by using the DEPLOYMENT variable.
Change-Id: Ifc87a12a2bb4ec4ff1c0a8dc8f0b1fbf37e4e513
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
clearly, this was a poor man's implementation of -force-debug-info.
Change-Id: Ib5c7e390bd0e3a6912af8c4027074a114ed33f8a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Visual Studio does not like empty dependencies block in manifest XML.
At least my Visual Studio 2013 fails to open visual manifest editor for
XML containing the following block:
<Dependencies>
</Dependencies>
If the block is removed or if the block has one or more PackageDependency
entries the editor accepts it.
Moved the <Dependencies> block to prf, so that it is only written when
project really has dependencies. Also <Capabilities> block is moved to prf
for consistency. On Windows Phone, where the <Capabilities> block is
required, it is kept in the output even if it is empty.
Change-Id: I531180d0081e4612f75be54f3813831857f1ed43
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qmlimportscanner is run as a $$system command (as opposed
to as a makefile command) so specify it as such to
qtPrepareTool and run it as such too.
The distinction is important for MinGW-w64 static
builds where it must be run via cmd.exe and not sh.exe.
Change-Id: I0832d5138bff7f4fa1968646df28d2367ad062c2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
testcase.prf cannot be loaded from pro file for various reasons,
see qtbase commit history for details.
Moved runtime testdata logic from pro file to testdata.prf, and
thus made is reusable in other test cases as well.
Change-Id: I500d08dc4951e4eda862071e4ddd3e0f6de8c3d2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
QMake always places makefiles, including vcproj files, to OUT_PWD.
BUILD_DIR i.e. QMAKE_RESOLVED_TARGET refers to location where target
is generated. If TARGET is specified in pro file with path, such as:
TARGET = ../../debug/tst_qlocale
The QMAKE_RESOLVED_TARGET refers to that path, and it differs from OUT_PWD.
Because Visual Studio requires a design-mode manifest in the same location
as the vcproj, resolved BUILD_DIR separately based on TEMPLATE.
Change-Id: I8dbaa862a5f53ac168f4643c17baabd7b4f0287d
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It may be much faster through the CI system that way.
Change-Id: Ib5e3a438bd2ac98dd0a3806cedba152f25e219d5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
If one doesn't set CONFIG+=neon in it's mkspec but the compiler enables
it, Qt fails during linking of libQtGui,
because simd.prf isn't executed as needed (doesn't run into neon{..}).
Although a mkspec which enabled neon (-mfpu=neon) without CONFIG+=neon
could be considered broken,
it's still simpler to just 'fix' Qt to not fail unexpected.
Follow-up to e5066a3a2e
Task-number: QTBUG-37264
Change-Id: I3aa0afbe430547971e76c2c988697c133d69796b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
