PageRenderTime 23ms CodeModel.GetById 20ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 0ms

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.
 4The main goal of using these is as follow:
 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.
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.
20To see an example of this, look at CoverStory
21( or Vidnik
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.
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).
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
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.
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