otherwise the project would need to clear QT despite using
qtHaveModule() in requires() (or REQUIRES=).
Task-number: QTBUG-65106
Change-Id: I568202214c8eafcdbe2d0e253b18f0e171293aff
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.
Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since Xcode 6.3, this must be set to NO because stripping on copy is no
longer fully supported due to the potential of input binaries being code
signed. In this case Xcode will simply ignore the strip step and issue
a warning since stripping would invalidate the code signature. This
change silences that annoying warning for release builds. Also, the
setting assignment is moved from being hardcoded in the generator, to
a QMAKE_MAC_XCODE_SETTINGS value.
Change-Id: If25511edddc12b7b0407e2992d80884b7d6437dc
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
If the linker supports it, add the gdb index to the debug symbols, which
makes loading gdb on Qt libraries much faster.
Change-Id: I2ed201c22913b97ac2efaefb5e31636e795ae102
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This works around the inability to build iOS apps for a "generic"
simulator by explicitly setting the Xcode build setting
ENABLE_ONLY_ACTIVE_RESOURCES to NO in order to ensure that all variants
of assets in an asset catalog are built when targeting iOS simulator
devices. Otherwise, we will simply build for whatever the first
simulator in the list happens to be. If the application is then deployed
to a different simulator, some of the assets needed for that device
variant may be missing.
This "helps" QTCREATORBUG-19447 but is not a workaround since this fix
is necessary for command line builds anyways, even though it's unlikely
to crop up in practice there, since one would have to manually deploy
the built application bundle to the simulator using simctl rather than
going through Xcode (which would rebuild for the appropriate device).
Change-Id: Ia41c48dcc715fe79a2c50db66a0ca7a1fea159c2
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... instead of only toolchain.prf.
the license check could go haywire, and everything else that file does
is meaningless in configure context anyway.
Task-number: QTBUG-63452
Change-Id: I5e31c87fe717fda40978c0317556070637e537e2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
otherwise test de-duplication between modules doesn't work.
Change-Id: I2c6222d853108df223758aa8907dc8d004efd87f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
especially during debugging, it is often necessary to re-run only one
(or a few) tests, where -recheck-all would be wasteful.
Task-number: QTBUG-64059
Change-Id: I9410894dec4289ff832d7f75e04f9b60fe76c57c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it could be somewhat surprising that specifying variant-specific libs
would not clear the common libs, so do that. of course, the default
for the common libs could theoretically contain common deps of the
variant-specific libs, in which case clearing them would be surprising
in turn - luckily, we have no such case.
Change-Id: Ifca08b9e1949c6a0cefed6931ade4021927d7c90
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... and not only when the source explicitly specifies build variants.
Change-Id: Iac6c8fda8f431d5fb50fada8338d1b660ab040d7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
unlike for the other fields, we forgot to eval() the values of the
build-specific library values, leading to over-quoting of values which
require any quoting at all.
amends c0cc50520.
Task-number: QTBUG-62521
Change-Id: I4dfce31040dd09248d3f9dd4294f7fb147c13bdd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
qtConfLibrary_inline() used to set $${1}.builds.$${b}.libs, while
everything else assumed no such .libs suffix. fix the former.
amends 9172143f52.
Task-number: QTBUG-61431
Started-by: Konstantin Ritt <ritt.ks@gmail.com>
Change-Id: I0bd81591c46266d81baa9c12315411183bbc7a63
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
For source packages that don't have a .git subdirectory, syncqt is
executed before configure, with outdir set to srcdir, and this
caused path misalignments for injected headers in qt_module.prf
when generating makefile rules.
The fix is to change syncqt to always output injected header
paths relative to the source dir.
Task-number: QTBUG-64539
Change-Id: Ia2296e44494093dbf124729062f430ad6fca7262
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This fixes an issue where a build error may be introduced by a simulator
being selected whose OS version is lower than the application's
minimum deployment target.
Task-number: QTBUG-64456
Change-Id: Ic7c834a1473c183ebb910bc01a416fe1e23a5a14
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We want to know when a plugin uses deprecated Qt APIs, especially
deprecations in the QPA APIs, which today is not the case, so
platform plugins have no idea that they should transition.
Change-Id: If9d3d95dc6f1f4178b103f177c9eb8326767ffab
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Bundle data source files which don't exist at qmake time need to be
handled specially. This also required splitting the generated list of
public headers, as was already done for private ones.
Task-number: QTBUG-60413
Change-Id: I97acfa88622da6b73839b8f976f73ace3cb10223
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This warning used to be part of -Wconversion, but that generates too
more noise than we're willing to fix now (like conversion from qint64 to
int). The float conversion does trigger for conversion from double to
float, as shown in all the QVectorND uses of float, but more
importantly, it triggers on passing floats to ints.
Change-Id: I69f37f9304f24709a823fffd14e69cfd33f75988
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
SYSTEM is used for system() calls, while SHELL is used in the target
Makefiles.
Task-number: QTBUG-62985
Change-Id: Ia75d3939c59c98699359421166433e8b4a6ee35e
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This guarantees that we have proper version checks in place for APIs on
Apple platforms that are not necessarily available on the deployment
target.
Change-Id: I10060f8b910f2bb790aa4a9c6f8c5cdc14d7cf06
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We obviously should check the variable we're about to get the data from.
Amends 1216f596bd.
Change-Id: Ibe87138b9c9aa99837b4fbf3769cd26ca1aaacb9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
If MOC_INCLUDEPATH exceeds a certain limit, its content is written into
a file named mocinclude.opt, which is then passed to moc as a response
file. That moc parameter was not properly quoted, and the moc call
failed for paths containing spaces.
Task-number: QTBUG-63197
Change-Id: Ib0542d80ce1bab239e0e6b6e24fadd11007b1846
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Amends cab060631
Task-number: QTBUG-62995
Change-Id: I374153ec34abad0585d2bcab0f699b42600be6ef
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This removes the pre-dexed JAR files activated by the absence of the
bundled_jar_file CONFIG option, as versions of Android >= 5 no longer
support this deployment mechanism.
Now, the "bundled" JARs simply become normal JARs containing class
files, and are neither activated by a bundled_jar_file CONFIG entry nor
do they have a -bundled suffix in the file's base name.
Task-number: QTBUG-62995
Change-Id: I3fa6819259be365b7a697f7db1d1d01a94032395
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Enabled via configure --ccache, or CONFIG += ccache in 3rd party
projects.
Ensures that we use the right sloppiness and other ccache options
during compilation.
Task-number: QTBUG-31034
Change-Id: I696b3d3f0398873a29b93d1bc2b4d4e06ef23dc9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Conflicts:
examples/examples.pro
qmake/library/qmakebuiltins.cpp
src/corelib/global/qglobal.cpp
Re-apply b525ec2 to qrandom.cpp(code movement in 030782e)
src/corelib/global/qnamespace.qdoc
src/corelib/global/qrandom.cpp
src/gui/kernel/qwindow.cpp
Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08)
src/network/ssl/qsslkey_openssl.cpp
src/plugins/platforms/android/androidjniinput.cpp
src/plugins/platforms/xcb/qxcbconnection.cpp
src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
src/widgets/widgets/qmenu.cpp
tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp
Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
When a ObjC++ QObject subclass is listed in the regular HEADERS, qmake
creates a .cpp file. The moc file will then fail to compile, as it
requries ObjC++ headers. Using Q_FORWARD_DECLARE_OBJC_CLASS() can be
used to let the class be parsed by The compiler, but link will still
fail, as the generated methods (e.g. signals) must be built with ObjC++
compiler, in case they have ObjC parameters:
Q_FORWARD_DECLARE_OBJC_CLASS(NSString);
class MyClass: public QObject {
Q_OBJECT
signals:
void objcSignal(NSString * myObj);
};
The canonical workaround for that is including the .cpp file into the
corresponding .mm file. This also offers a compilation speed advantage,
but is somewhat counter-intuitive.
Therefore, we introduce a separate variable which instructs moc to create
.mm files directly.
Task-number: QTBUG-1581
Change-Id: Ia98af58006efd168ea37f3a63c396979e7e81baa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
