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