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

73 lines
2.8 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)
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_SDK_PATH = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.path)
}
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_OBJECTIVE_CFLAGS += -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
for(tool, $$list(QMAKE_CC QMAKE_CXX QMAKE_FIX_RPATH QMAKE_AR QMAKE_RANLIB QMAKE_LINK QMAKE_LINK_SHLIB)) {
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)
Enable C++11 on OSX when using Clang This means we have to bump the deployment target to Lion (10.7), as the LLVM 'libc++' C++ standard library does not support Snow Leopard (10.6). For iOS the deployment target has to be bumped from 4.3 to 5.0, but we don't enable C++11 by default yet as it's not tested enough on iOS. Users who wish to deploy to 10.6 need to build their own Qt, passing -no-c++11 to configure. Change-Id: I7b5d20ab002db889d1091a4b7ff600f62caa7f06 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-04-03 13:05:06 +00:00
# C++11 support may affect the deployment target
c++11: load(c++11)
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
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_OBJECTIVE_CFLAGS += $$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