- GTM_INLINE will make sure a function gets inlined, and provides a consistent

  way for all GTM code to do it.

- Added GTMDebugThreadValidation to allow you to enforce the fact that your
  code must run in the main thread in DEBUG builds.

- Updated some internals of the iPhone unittesting so it doesn't double print
  the test descriptions, file names, or lines numbers of a test failure line.
  Also includes the test names in the error output.

- Changed the xcconfigs so that know it's easier to set different settings at
  the different levels and not accidentally overwrite settings set at lower
  levels in the "settings collapse". Also tightened up warnings significantly.

- Changed how gtm_unitTestExposedBindingsTestValues works. If you have an
  implementation of gtm_unitTestExposedBindingsTestValues in your own code
  you will need to update to the new way of calling. See implementations in
  GTMNSObject+BindingUnitTesting.m for details.

- Added support for grabbing the build number for a particular OS in
  GTMSystemVersion and easily comparing it to known build numbers, and switched 
  some types from in GTMSystemVersion from "int" to SInt32 to make 64 bit work 
  better.
   
- Added support for SnowLeopard (10A96). We build cleanly with the 10.6 SDKs and
  all radar checks were updated accordingly. Build All script was also updated
  to build on SnowLeopard if you have the SDK available.
  
- Turned off building ppc64 GTM because the SnowLeopard SDK currently
  doesn't have ppc64 support, so SenTestCase isn't defined. This makes it
  impossible to build the ppc64 10.5 config on SnowLeopard. We have left the
  setting in the xcconfig for those of you who need it, but have disabled
  it in the GTM project settings.
  
- Turned on stack smashing protection on the debug builds for all Leopard 
  and above.

- Added ability to easily do leak checking by defining the GTM_ENABLE_LEAKS
  environment variable. It isn't on by default because several of Apple's
  frameworks leak. You can work around these false positives by using the
  GTM_LEAKS_SYMBOLS_TO_IGNORE environment variable. Also if you turn on leaks
  make sure to turn off zombies by defining the GTM_DISABLE_ZOMBIES variable,
  otherwise every memory allocation you do will look like a leak.

1 files changed, 23 insertions, 2 deletions

diff --git a/XcodeConfig/xcconfigs-readme.txt b/XcodeConfig/xcconfigs-readme.txt
index 5a44bb0..87a6dd7 100644
--- a/XcodeConfig/xcconfigs-readme.txt
+++ b/XcodeConfig/xcconfigs-readme.txt
@@ -1,4 +1,4 @@
-Xcode Config is sorta a black art, any time you have a set of rules, you
+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:
@@ -6,7 +6,7 @@ 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.  This will batch setup the project to
-build Debug/Release w/ a specific SDK.
+build Debug/Release with a specific SDK.
 
 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
@@ -30,3 +30,24 @@ 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.