AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6c2d786e19
qt5base-lts/mkspecs/features/mac/sdk.prf

84 lines
3.5 KiB
Plaintext
Raw Normal View History

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>
2013-02-15 17:11:04 +00:00
Make host_build re-use the sdk.prf logic 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>
2013-03-01 12:28:03 +00:00
isEmpty(QMAKE_MAC_SDK): \
error("QMAKE_MAC_SDK must be set when using CONFIG += sdk.")
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>
2013-02-15 17:11:04 +00:00
Make host_build re-use the sdk.prf logic 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>
2013-03-01 12:28:03 +00:00
contains(QMAKE_MAC_SDK, .*/.*): \
error("QMAKE_MAC_SDK can only contain short-form SDK names (eg. macosx, iphoneos)")
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>
2013-02-15 17:11:04 +00:00
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
isEmpty(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.path) {
QMAKE_MAC_SDK_PATH = $$system("/usr/bin/xcodebuild -sdk $$QMAKE_MAC_SDK -version Path 2>/dev/null")
isEmpty(QMAKE_MAC_SDK_PATH): error("Could not resolve SDK path for \'$$QMAKE_MAC_SDK\'")
use the new "stash" instead of the (anything but) "regular" cache as this new cache category comes without side effects, we can unconditionally create a cache whereever we are. this allows us to be performant without explicit user action. Task-number: QTBUG-31340 Change-Id: I6b88b20b61e8351aa8cbf94ad3eec65adac6e1d6 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-31 19:27:54 +00:00
cache(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.path, set stash, QMAKE_MAC_SDK_PATH)
Decouple caching of iOS/OSX SDK path and version in sdk.prf 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>
2014-12-01 11:59:16 +00:00
} else {
QMAKE_MAC_SDK_PATH = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.path)
}
qmake: Expose iOS/OS X SDK platform path as QMAKE_MAC_SDK_PLATFORM_PATH Change-Id: I2e58c22301a433208718c26b362b4dda2b891f0e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-02-13 14:17:47 +00:00
isEmpty(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_path) {
QMAKE_MAC_SDK_PLATFORM_PATH = $$system("/usr/bin/xcodebuild -sdk $$QMAKE_MAC_SDK -version PlatformPath 2>/dev/null")
isEmpty(QMAKE_MAC_SDK_PLATFORM_PATH): error("Could not resolve SDK platform path for \'$$QMAKE_MAC_SDK\'")
cache(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_path, set stash, QMAKE_MAC_SDK_PLATFORM_PATH)
} else {
QMAKE_MAC_SDK_PLATFORM_PATH = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_path)
}
Decouple caching of iOS/OSX SDK path and version in sdk.prf 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>
2014-12-01 11:59:16 +00:00
isEmpty(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.version) {
mkspec macx-ios-clang: ensure SDK version is valid 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>
2014-11-08 18:30:56 +00:00
QMAKE_MAC_SDK_VERSION = $$system("/usr/bin/xcodebuild -sdk $$QMAKE_MAC_SDK -version SDKVersion 2>/dev/null")
isEmpty(QMAKE_MAC_SDK_VERSION): error("Could not resolve SDK version for \'$$QMAKE_MAC_SDK\'")
cache(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.version, set stash, QMAKE_MAC_SDK_VERSION)
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
} else {
mkspec macx-ios-clang: ensure SDK version is valid 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>
2014-11-08 18:30:56 +00:00
QMAKE_MAC_SDK_VERSION = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.version)
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
}
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>
2013-02-15 17:11:04 +00:00
Make host_build re-use the sdk.prf logic 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>
2013-03-01 12:28:03 +00:00
!equals(MAKEFILE_GENERATOR, XCODE) {
QMAKE_CFLAGS += -isysroot $$QMAKE_MAC_SDK_PATH
QMAKE_CXXFLAGS += -isysroot $$QMAKE_MAC_SDK_PATH
QMAKE_LFLAGS += -Wl,-syslibroot,$$QMAKE_MAC_SDK_PATH
}
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. We unset PERL5LIB to ensure we get the system Perl libraries, since the Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from macports/CPAN. Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-15 16:27:51 +00:00
Make host_build re-use the sdk.prf logic 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>
2013-03-01 12:28:03 +00:00
sysrootified =
for(val, QMAKE_INCDIR_OPENGL): sysrootified += $${QMAKE_MAC_SDK_PATH}$$val
QMAKE_INCDIR_OPENGL = $$sysrootified
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. We unset PERL5LIB to ensure we get the system Perl libraries, since the Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from macports/CPAN. Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-15 16:27:51 +00:00
Scope cached Mac SDK tool values by mkspec Otherwise doing stuff like -spec macx-g++ when the default spec is clang will not have an effect on the tools used. Change-Id: Ia2769abfdd8c19f79d427b9f09707430e736305a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-06-13 12:18:10 +00:00
QMAKESPEC_NAME = $$basename(QMAKESPEC)
Use tools from the SDK's toolchain instead of the ones in /usr/bin 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>
2013-02-27 14:01:25 +00:00
# Resolve SDK version of various tools
Add the ability for qmake to build Xcode asset catalogs This essentially emulates Xcode behavior for QMAKE_BUNDLE_DATA. This is mostly for our own internal use. No documentation is provided. Variables introduced: - QMAKE_ASSET_CATALOGS - QMAKE_ASSET_CATALOGS_APP_ICON - QMAKE_ASSET_CATALOGS_BUILD_PATH - QMAKE_ASSET_CATALOGS_INSTALL_PATH Change-Id: I9577415d637f022d05f301c5a0d799483cd2a963 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-05-04 09:08:44 +00:00
for(tool, $$list(QMAKE_CC QMAKE_CXX QMAKE_FIX_RPATH QMAKE_AR QMAKE_RANLIB QMAKE_LINK QMAKE_LINK_SHLIB QMAKE_ACTOOL)) {
Scope cached Mac SDK tool values by mkspec Otherwise doing stuff like -spec macx-g++ when the default spec is clang will not have an effect on the tools used. Change-Id: Ia2769abfdd8c19f79d427b9f09707430e736305a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-06-13 12:18:10 +00:00
tool_variable = QMAKE_MAC_SDK.$${QMAKESPEC_NAME}.$${QMAKE_MAC_SDK}.$${tool}
!isEmpty($$tool_variable) {
$$tool = $$eval($$tool_variable)
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
next()
}
Use tools from the SDK's toolchain instead of the ones in /usr/bin 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>
2013-02-27 14:01:25 +00:00
value = $$eval($$tool)
isEmpty(value): next()
Use absolute paths for Xcode helpers such as xcodebuild/xcrun/xcode-select We always use the xcodebuild/xcrun/xcode-select binaries in /usr/bin, as these will dispatch to the right binary based on what Xcode version has been chosen using xcode-select -switch. This fixes an issue where a tool was in the path from another Xcode installation. We can rely on the tools as they are present on a clean Mac OS install. Change-Id: I1d3cc1e92604f9be6d6f14639cb6322234edd696 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-04-08 14:34:33 +00:00
sysrooted = $$system("/usr/bin/xcrun -sdk $$QMAKE_MAC_SDK -find $$first(value) 2>/dev/null")
Handle errors when sysrooting tools on Mac xcrun will spit out errors to stderr and nothing to stdout if it fails to find the tool in question. By checking for an empty return value and skipping the sysrooting we guard against mangling the tool variable. Change-Id: I68f59a6c8116696dd75cceed7b33ac666f3468b2 Reviewed-by: Eike Ziller <eike.ziller@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-04-08 10:17:27 +00:00
isEmpty(sysrooted): next()
Use tools from the SDK's toolchain instead of the ones in /usr/bin 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>
2013-02-27 14:01:25 +00:00
$$tool = $$sysrooted $$member(value, 1, -1)
use the new "stash" instead of the (anything but) "regular" cache as this new cache category comes without side effects, we can unconditionally create a cache whereever we are. this allows us to be performant without explicit user action. Task-number: QTBUG-31340 Change-Id: I6b88b20b61e8351aa8cbf94ad3eec65adac6e1d6 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-31 19:27:54 +00:00
cache($$tool_variable, set stash, $$tool)
Use tools from the SDK's toolchain instead of the ones in /usr/bin 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>
2013-02-27 14:01:25 +00:00
}
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
isEmpty(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_name) {
Use PlistBuddy instead of sed/xpath magic to extract OS X/iOS SDK name Change-Id: I9e9f9b033cc892a35c86b35f64dc1dd915ad44f3 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Eike Ziller <eike.ziller@digia.com> Reviewed-by: Jake Petroules <jake.petroules@petroules.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-04-01 13:05:20 +00:00
QMAKE_MAC_PLATFORM_NAME = $$system("/usr/libexec/PlistBuddy -c 'print DefaultProperties:PLATFORM_NAME' $$QMAKE_MAC_SDK_PATH/SDKSettings.plist 2>/dev/null")
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
isEmpty(QMAKE_MAC_PLATFORM_NAME): error("Could not resolve platform name for SDK '$$QMAKE_MAC_SDK'")
use the new "stash" instead of the (anything but) "regular" cache as this new cache category comes without side effects, we can unconditionally create a cache whereever we are. this allows us to be performant without explicit user action. Task-number: QTBUG-31340 Change-Id: I6b88b20b61e8351aa8cbf94ad3eec65adac6e1d6 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-31 19:27:54 +00:00
cache(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_name, set stash, QMAKE_MAC_PLATFORM_NAME)
Cache Xcode and SDK settings in .qmake.cache if it exists The Xcode and SDK settings are expensive to resolve, as we're using system() calls to resolve them. We now try to detect the presence of a .qmake.cache file (and inform the user that creating one would be a good idea), and use the file to cache the various settings after resolving them. The Xcode logic had to be moved form xcode.conf as part of the mkspec, into default_pre/post.prf, so that we could cache() the resolved values. Task-number: QTBUG-30586 Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 10:21:05 +00:00
} else {
QMAKE_MAC_PLATFORM_NAME = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.platform_name)
}
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. We unset PERL5LIB to ensure we get the system Perl libraries, since the Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from macports/CPAN. Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-15 16:27:51 +00:00
!equals(MAKEFILE_GENERATOR, XCODE) {
iOS: Replace device and simulator makespecs with single makespec 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>
2012-11-20 14:25:34 +00:00
# FIXME: Get the version_min_flag out of the platform's 'Native Build System.xcspec'
version_identifier = $$replace(QMAKE_MAC_PLATFORM_NAME, iphonesimulator, ios-simulator)
ios:!host_build: \
deployment_target = $$QMAKE_IOS_DEPLOYMENT_TARGET
else: \
deployment_target = $$QMAKE_MACOSX_DEPLOYMENT_TARGET
version_min_flag = -m$${version_identifier}-version-min=$$deployment_target
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. We unset PERL5LIB to ensure we get the system Perl libraries, since the Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from macports/CPAN. Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-15 16:27:51 +00:00
QMAKE_CFLAGS += $$version_min_flag
QMAKE_CXXFLAGS += $$version_min_flag
QMAKE_LFLAGS += $$version_min_flag
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
}
Reference in New Issue Copy Permalink