Plain Text | 57 lines | 47 code | 10 blank | 0 comment | 0 complexity | 2d30f072711513f1689f197823b95e65 MD5 | raw file
1Xcode Configs are sort of a black art, any time you have a set of rules, you 2quickly hit a few exceptions. 3 4The main goal of using these is as follow: 5 6Edit your Project level build settings by removing as much as possible, and 7then set the per Configuration settings to one of the project xcode config 8files w/in the Project subfolder here. Apple now recommends always building 9with the "current" SDK and started being more aggressive at removing older 10SDKs with each Xcode releases. So set you SDK version and min supported OS 11version in your project. The configs will then set everything based off 12those choices. 13 14 15If you are building a Shared Library, Loadable Bundle (Framework) or UnitTest 16you will need to apply a further Xcode Config file at the target level. You do 17this again by clearing most of the settings on the target, and just setting the 18build config for that target to be the match from the Target subfolder here. 19 20To see an example of this, look at CoverStory 21(http://code.google.com/p/coverstory) or Vidnik 22(http://code.google.com/p/vidnik). 23 24 25The common exception...If you need to have a few targets build w/ different 26SDKs, then you hit the most common of the exceptions. For these, you'd need 27the top level config not to set some things, the simplest way to do this seems 28to be to remove as many of the settings from the project file, and make new 29wrapper xcconfig files that inclue both the project level and target level 30setting and set them on the targets (yes, this is like the MetroWerks days 31where you can quickly explode in a what seems like N^2 (or worse) number of 32config files. With a little luck, future versions of Xcode might have some 33support to make mixing SDKs easier. 34 35Remember: When using the configs at any given layer, make sure you set them for 36each build configuration you need (not just the active one). 37 38Many of the build settings are more than just yes/no flags and take 39a list of values that you may want to change at different levels. 40Xcode doesn't allow you to "inherit" settings with includes so you always 41end up overriding settings accidentally. To avoid this, we instead 42allow you to define settings at different levels 43(GENERAL, PLATFORM (iPhone/Mac), CONFIGURATION (Release/Debug). 44We do this by setting a GTM version of the setting (so for OTHER_CFLAGS it's 45GTM_XXX_OTHER_CFLAGS where xxx is GENERAL, PLATFORM or CONFIGURATION depending 46at what level the flag is set. These are all merged together in the 47GTMMerge.xcconfig. Do not modify the base setting (OTHER_CFLAGS) instead modify 48the GTM one at the level you want it modified. 49 50The major place this may affect you is that we have really tightened down on 51the warnings. To make it easier for you to move your code onto the new 52xcconfig files, we have split the warnings up into three categories, which in 53general you can think of as easy, moderate and extreme. If you run into a lot 54of warnings when you compile, look at changing the GTM_GENERAL_WARNING_CFLAGS 55setting to only include lower levels (eg GTM_GENERAL_WARNING_CFLAGS1) and see 56if that makes it easier on you. Look inside General.xcconfig and search for 57GTM_GENERAL_WARNING_CFLAGS1 for more info.