bootstrapping is only necessary if we are cross-compiling or have a
circular build dependency.
Change-Id: I17244457652ca9d4fc797043e57070c2ae3ee5d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Qt uses a lot of minor C++11 extensions such as long long, commas at the
end of enumerator lists, and extra ';' outside of a functions, and not all
of these can be silenced, so we build without warnings for C++11 extensions,
since we plan to enable C++11 at some point anyways.
Change-Id: I3ede2fb653c25475a3bd2b860c0c80c6cf6abef5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The 'silent' option to CONFIG will mangle QMAKE_CXX and friends by prepending
an @echo, which sdk.prf doesn't handle (it assumes the variables contain
names of executables, with optional arguments). Instead of teaching sdk.prf
generic command line parsing we ensure that silent.prf does its job at the
very end, when the tools have already had their paths fixed by sdk.prf.
Change-Id: I7093232e5cc37ed8106a3b838f42ad8f1a43fb86
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
For Mac OS X we currently specify build tools without an absolute path,
which means we end up using the ones in /usr/bin. This is wrong, we
should be using the tools from the toolchain of the chosen SDK.
For iOS we do specify an absolute path, by resolving the toolchain
path in the iOS makespecs.
To solve the situation on Mac OS X, we move the logic of resolving the
toolchain path to sdk.prf, and share it between OSX and iOS.
For configure we need to duplicate some of the logic from sdk.prf, as
configure pulls out QMAKE_CC and QMAKE_CXX for running some initial
tests and building qmake. The new macSDKify function also solves
the issue of missing sysroot and deployment version in the flags.
Change-Id: Ib1d239c9904cf3ccee5214b313cf6205869a1462
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We now take advantage of the fact that xcodebuild -version allows you to
pass the key that you're interested in, to only print that single value.
This technique is used by Apple's own build scripts as well.
Change-Id: I57b8424590d4137a0e7f263a318e17ee2e0dfad4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
so far the assumption was that every qml plugin/module in qt is a
wrapper/extension of a corresponding qt module. this not the case for
the upcoming quickcontrols, for example.
Task-number: QTBUG-28200
Change-Id: If4b8bb6633e76b2a510908d09a010cee12d33634
Reviewed-by: Liang Qi <liang.qi@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
It is unused in the source code and replaced by Q_OS_LINUX,
Q_OS_ANDROID and Q_OS_ANDROID_NO_SDK depending on usecase.
Change-Id: If8d561540e7583fbac83c0f3506f219c4433e847
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Introduced Q_OS_ANDROID_NO_SDK which makes more sense than
Q_OS_LINUX_ANDROID when Q_OS_ANDROID also defines Q_OS_LINUX.
Change-Id: Id2aa228b66daffba82776a12c91a264a360afd86
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
We want the second member from 'Xcode 4.x', and $$first() gave us
'Xcode' instead of the version number.
Change-Id: Iaf0ed9dc89a03f7918290a61bddade82651ad0f6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The former applies both on Mac OS X and iOS, but 'macx' is specific to
Mac OS X.
ios.conf and macx.conf now share most of their settings in the common
mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so
that any overrides in the device config will apply afterwards. This
means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK.
Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
The only difference between the two is that iOS append @executable_path/
to QMAKE_LFLAGS_SONAME, but since shared libraries are not supported on
iOS anyways, this is not really something we have to care about.
Change-Id: I4797a4dfb94d9b3af03af22618351b98b48f8255
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This is a step towards making mac a shared scope for both Mac OS X and
iOS, while macx is Mac OS X specific and ios is iOS specific.
We'll then move iOS to not include macx.conf, once we make the change
to not have iOS imply macx.
Change-Id: Ic9ce4d597873aa3cf2c981598354733e07db644d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
If there are minor differences later on we can put them in the
mkspecs' forwarding header and/or introduce a macx specific file.
Change-Id: I2a93107838e0d8434c0d444db3064e0a462fa656
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Based on the Necessitas project by Bogdan Vatra.
Contributors to the Qt5 project:
BogDan Vatra <bogdan@kde.org>
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
hjk <hjk121@nokiamail.com>
Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Paul Olav Tvete <paul.tvete@digia.com>
Robin Burchell <robin+qt@viroteck.net>
Samuel Rødal <samuel.rodal@digia.com>
Yoann Lopes <yoann.lopes@digia.com>
The full history of the Qt5 port can be found in refs/old-heads/android,
SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d
Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
If the command is quoted, it can contain anything but quotes (we do not
support escaped quotes, so single quotes have to be used). If the
command is unquoted we look for the first closing parenthesis. We used
to do this using .*?, but the greedy modifier '?' didn't seem to work,
so we now use an inverse character set.
Change-Id: I40660ce7aef6a6b6d480292d28da1b079bb161da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Instead of hard-coding the SDK and deployment target.
A host build will already use the host-makespec, so now that we
always build against an SDK, these mkspecs will have the SDK and
deployment target set.
Change-Id: I2b0343ae75f7de12081bab8346307b96b3883f62
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is enabled only for -developer-builds and only for certain
compiler-version combinations that are in a whitelist.
It also requires each library, plugin or tool to declare whether it is
supposedly clean of warnings. When most targets are clean, we can
consider inverting.
Change-Id: I17b5c4e45aee5078f9788e846a45d619c144095a
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We don't want to hit the network, as a flakey network or slow server will
hang the XML parsing. We assume the XML is well formed.
Change-Id: Idc4898a925a46222954bf633a04ea9fe148c6797
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This file is now included by three types of Qt output: modules,
plugins (including QML plugins) and tools.
Change-Id: I5085f6ff37f70e9228303bf0520040adc2e2d7a5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We need to figure out where to draw the line when it comes to warning
about unknown compiler (Clang), Xcode, or SDK versions, but for now
building with Xcode 4.6 should not be an issue. We'll have to revisit
this and test with the full set of compiler/Xcode/SDKs we support
before the final release.
Change-Id: Iac3ec3a25c0f7618b2c3714657d147f17f834d97
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
At some point we want to build with C++11 support, but for now we silence
the warning.
Change-Id: I40deb0925d459eaf06e324dddc0a2e9893c57615
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
configure.prf checks if MAKEFILE_GENERATOR is set
to something it can work with. ios/default_pre.prf
unsets MAKEFILE_GENERATOR.
This breaks QtMultimedia at least. Add special case
for iOS to configure.prf and set QMAKE_MAKE to "make".
Change-Id: Ie8feaeefe4a932d735a0cd4c09e869ca1341aae5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Defining QT_QPA_DEFAULT_PLATFORM_NAME in qplatformdefs.h is not
neccecary, as qconfig.h will already have this define written by
configure.
Change-Id: I89d9191533f6b4e6bfd5eade6cc0dced02b50f81
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Change-Id: Ic04da6063863585665c9133caba0279ba478fbb4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
In case they provide their own main that calls UIApplicationMain.
Change-Id: Ia050277ae5cbcbf01bc57b87ec37a74db9568059
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Ideally we'd only have to do QTPLUGIN += ios, but this doesn't work as
we need to link with the force_load linker option. Even trying to build
on QTPLUGIN and then replace the -l line with what we need will fail, as
the prl logic in qmake which runs after all the prf files does not know
about the force_load option and will then fail to resolve dependencies
from the prl file.
Since we load the platform plugin using -force_load, there's no need to
generate a cpp file that does the plugin import.
The main wrapper is not a real Qt plugin, and doesn't have an import
function that we can call, so we link it manually instead of relying
on QTPLUGIN.
Change-Id: I0381a3c9ed7f8d41a4121e1fc0b7c0e210a8b832
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
As long as Qt Creator does not provide any iOS integration, and the
app bundle we create using the Makefile generator is not good enough
to deploy to a device anyways, producing Xcode projects make the most
sense.
We base the decicion on whether or not the project depends
on QtGui and has app_bundles enabled. This prevents configure
tests and other tools from having Xcode projects, but allows
examples and demos to build out of the box.
Instead of setting the generator unconditionally we unset it in
default_pre so that we can detect if the user set it manually. This
means the user won't be able to inspect the MAKEFILE_GENERATOR variable
from the pro file, but this is less of a use-case then overriding the
generator from the command line or prooject file.
Change-Id: I881cf3e29631445f83ea4ff0979f7a566e4810f5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
And use configure's -sdk argument to choose between the iphoneos and the
iphonesimulator SDK. xcodebuild -showsdks can be used to list the
available SDKs. Passing an SDK without a version postfix implies
the latest version of the SDK.
Change-Id: I881df754d522fc91aaa16ba3e39cf0c37a21a1f1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Instead we deal with any differenced by setting variables in the top
level makespecs, that are used by the common makespec configs.
Change-Id: Iae1fb5fef8c95778511ed400008731989b446f3c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
NEON detection is handled by configure's arch test, and THUMB2 is the
default for ARMv7.
Change-Id: I8ec3ce0ec6af9ad8d9509890aa1f8c87e18364d5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
We now require SDK version 4.3 or above, and armv7.
Change-Id: I4766e277a3a4a32712bf2ec27fede694e8316c95
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
There's no need to duplicate the logic for device vs simulator. The only
difference is the iPhoneOS/iPhoneSimulator name.
Change-Id: I87c57fa785279a3ee258b76fdac8317e52e7daa2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
We treat iOS as a variant of Mac OS, so for iOS both Q_OS_MAC and
Q_OS_IOS will be defined. This matches what Apple assumes in the
header file TargetConditionals.h
Change-Id: I55cc851401b748297478e4c32e84e0f6e1fdfc28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We can use xcode-select -print-path to get the /Developer directory.
This also removes the need for the "legacy" makespecs, which only
differ from their non-legacy counterparts in the location of the
Xcode developer directory.
Change-Id: Ia9245033a4b82cc3933226bf998f07177b60871f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>