Ensure that arch.test for host runs with option(host_build)

So that mkspecs and features may rely on the host_build test.

Change-Id: I18fee4820d9e2904285afcc7ddb8f1cc3d025fef
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Update feature paths on assignment to QMAKE_PLATFORM

Instead of after parsing the makespecs, were we assumed QMAKE_PLATFORM
had been set by the makespec and did an explicit update.

Allows loading platform specific features from within a makespec after
updating QMAKE_PLATFORM.

Change-Id: I0eb3b7fb88ce48b00a384850c5d87223c06234d7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Remove deprecated use of QMAKE_MAC_SDK in corewlan.pro

We no longer support OS X < 10.6, so there's no need to check for it.

Change-Id: I2628984846de0c0c19ea86b3ba6d00fc370ddae7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Clean up how we build against SDKs on Mac OS

Instead of setting -isysroot in both arch.test, compile.test, the various
mkspecs, and sdk.prf, we now propgate the chosen SDK as the qmake
variable QMAKE_MAC_SDK, which is then handled exclusivly in sdk.prf.

The QMAKE_MAC_SDK variable, and -sdk argument to configure, is expected
to be of the short-form name, eg macosx or iphoneos, not a full path, as
that's what Xcode also expects. We take care of translating that into
a full path for -isysroot/-syslibroot in sdk.prf, using xcodebuild as
a helper.

Change-Id: I281655b2fa5180c6e78ffdce36824e4a91447570
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Always build against an SDK on Mac OS

Building against the local /System can cause build issues when for example
the headers have not been updated to reflect the system version. The system
headers are updated as part of installing the command line tools from within
Xcode, not as part of the system update process, so we might think we are
on 10.8, but the system headers will not reflect that, and we get build
breaks. It's preferable to always build against an SDK, so that we have
a known state for the OS X libraries and headers.

We choose the latests SDK by default, as recommended by Apple.

Change-Id: I79028217ff3a9cbe45aa4cb05ed6dd90388dee50
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Use sdk.prf to set macosx-version-min instead of static conf files

Allows us to dynamically generate the command line option for iOS later,
and allows the user to override QMAKE_MACOSX_DEPLOYMENT_TARGET with the
expected effect on the command line options.

Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Don't link QtPlatformSupport to CoreFoundation or Carbon

Move the Carbon dependency to the Cocoa platform plugin instead, where
it's actually used.

CoreFoundation was not used by any plugins and could be removed
completely.

Change-Id: I1c825cdf94e2cc348ea13519b894fd868be0d14a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Xcode: Merge various sources and extra-compilers into more managable groups

Instead of letting each qmake variable have its own auto-generated name
we try to group common variables into similar groups as used by the Xcode
templates provided by Apple.

We also prevent the same files from ending up multiple times in a group.

Change-Id: I73b13d6071bb7b3cd1501c422a99c60743221485
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Xcode: Change groups/build phase wording to match Apple's templates

Change-Id: I286965a05750bc77b94ca4d3b76364b0130e32ed
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
qmake: Update Xcode generator to produce project files similar to Xcode

There was quite a bit of cruft left over from older Xcode version. We
now produce Xcode 3.2 compatible files, similar to what Xcode would do
when asked to upgrade one of our generated files. In particular:

 - Removed refType
 - Set more lastKnownFileTypes
 - Renamed defaultConfigurationIsName to defaultConfigurationName
 - Add runOnlyForDeploymentPostprocessing = 0 to build phases
 - Don't put buildSettings directly into PBXNativeTarget
 - Don't write productSettingsXML
 - Don't write startupPath
 - Don't write name when path is the exact same
 - Write empty buildSetting lists as empty string
 - Don't write empty PBXBuildFile settings
 - Don't write generated/neede filenames for PBXShellScriptBuildPhase
 - Use PBXFileReference instad of PBXFrameworkReference
 - Prune deprecated buildSetting variables
 - Remove deprecated PBXBuildStyle sections
 - Resolve correct CC/CPLUSPLUS/LDPLUSPLUS
 - Write IPHONEOS_DEPLOYMENT_TARGET

Change-Id: Ia2365c2623fe898878bd10636c3b85145c1cff04
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
qmake: Don't generate Xcode project bundle identifiers with spaces

Replace them with dashes, like Xcode itself does.

Change-Id: I302425363a2eef13394025cd4a9e414048ce55ce
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
qmake: Prevent duplicate libaries from being added to the link phase

Change-Id: I5ec7acb8f060e9d9bbd8cdb95d40ace03cffe9c7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
qmake: Don't treat .xcodeproj directories as OUT_PWD when passed with -o

The Xcode generator creates a makefile for running 'make qmake', and the
makefile passes -o to ensure it writes to the same Xcode project. This
fails when qmake then treats -o foo.xcodeproj/project.xcproj as not only
setting the output filename, but also the output directory to foo.xcodeproj,
which results in the Xcode project trying to reference files relative
to this directory, such as '../main.cpp'.

Unfortunatly the output filename parsing happens too early for us to know
whether or not the generator is Xcode, so we just have to assume that
a certain combination of output filename and directories means we are
generating an Xcode project.

Change-Id: I0901d4db995f287c35cbbbd015683d5abda6d0f5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
qmake: Use PBXResourcesBuildPhase for QMAKE_BUNDLE_DATA without a path

The PBXResourcesBuildPhase will optimize resources, such as turning XIB
files into NIB files, running pngcrush on images, turning string files
into binary plists, etc, so we prefer that if possible.

Unfortunatly this phase does not support custom paths, so whenever we
encounter bundle data with a custom path we fall back to the regular
PBXCopyFilesBuildPhase.

Change-Id: I539db03dd7982fd37293123b6428cdb695f64d2b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
qmake: Prevent Obj-C sources from building both as extra compiler and in Xcode

We already assume that if a source is buildable and should end up in OBJECTS we
can let Xcode build it, so we skip this input for the extra compiler.

Change-Id: I17b2408925b8e6513f0fa0d2459ec539bf7381d3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qmake: Fix file paths in Xcode projects when shadow-building

The Xcode generator seems to have been written with the assumption that
writeMakeParts() would be called with the output directory as the current
directory, but that's not the case when shadow-building. Perhaps this
was changed in qmake at some point, and the Xcode generator was not
updated to reflect that.

Instead of replacing every occurance of fileFixify and other logic to
deal with paths, we just chdir into the output_dir for the duration
of the function (except when writing the 'make qmake' makefile, as
the regular makefile generator works as expected with the current
directory set to the input directory).

Change-Id: I6ba492036d73f29f4adbd7cd554db9504050629e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
qmake: Resolve QMAKE_INFO_PLIST against current working dir

We're not in the output directory yet, so resolving using vanilla
fileFixify will end up failing when we check if the file exists, since
QFileInfo resolves relative paths against the current directory.

Change-Id: I414c6a2e83b49e3fb30e6153a49f7a90a8e528a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
iOS: Remove hard-coding of Xcode /Developer path in common/ios mkspecs

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>
iOS: Get rid of GCC/LLVM makespecs for iOS

We only want to support Clang.

Change-Id: Id0558df905106158f4c25ca10462bf4ca41e1e45
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
iOS: copy brute-force port of Qt4 uikit plugin into Qt5.

The plugin has been renamed from uikit to ios.
Other than that, the plugin will now build, but do nothing. Most of
the Qt4 code is preserved, with a rough translation
into the Qt5 qpa API. A lot of code has simply been commented
out so far, and most lacking at the moment is the event dispatcher
which will need to be rewritten, and the opengl paint device
implementation. But it should suffice as a starting ground.

Also: The plugin will currently not automatically build when
building Qt, this needs to be enabled from configure first.

Change-Id: I0d229a453a8477618e06554655bffc5505203b44
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>