Pull out SDKROOT into a gyp variable

This change allows you to specify SDKROOT using a GYP variable, so the default setting (macos10.6) can be overridden.  This allows building on Lion or Mountain Lion using XCode 4.

(Ideally, we should be sniffing the OS version and setting it automatically, but I didn't do that here.)

[epoger, 2012-09-20 14:59:07]

Adding Cary... I think he said we could just make it "macosx" instead of
"macosx10.6" and it would work.  Right, Cary?

[EricB, 2012-09-20 14:59:32]

https://codereview.appspot.com/6553044/diff/1/gyp/common_variables.gypi
File gyp/common_variables.gypi (right):

https://codereview.appspot.com/6553044/diff/1/gyp/common_variables.gypi#newco...
gyp/common_variables.gypi:81: 'skia_sdkroot%': 'macos10.6',
I suggest something more descriptive like "skia_osx_sdk" so that we know what
sdk we're talking about.

[Stephen White, 2012-09-20 15:14:03]

On 2012/09/20 14:59:32, EricB wrote:
> https://codereview.appspot.com/6553044/diff/1/gyp/common_variables.gypi
> File gyp/common_variables.gypi (right):
> 
>
https://codereview.appspot.com/6553044/diff/1/gyp/common_variables.gypi#newco...
> gyp/common_variables.gypi:81: 'skia_sdkroot%': 'macos10.6',
> I suggest something more descriptive like "skia_osx_sdk" so that we know what
> sdk we're talking about.

Done.

[Stephen White, 2012-09-20 15:15:43]

On 2012/09/20 14:59:07, epoger wrote:
> Adding Cary... I think he said we could just make it "macosx" instead of
> "macosx10.6" and it would work.  Right, Cary?

I'm happy to make that change (I find that on XCode4 + MountainLion, I can
simply "unset it", and everything works too), but I don't have a 10.6 machine to
see if that would work there.  I could land it and just watch the bots, I
suppose.

[Stephen White, 2012-09-20 15:21:08]

On 2012/09/20 15:15:43, Stephen White wrote:
> On 2012/09/20 14:59:07, epoger wrote:
> > Adding Cary... I think he said we could just make it "macosx" instead of
> > "macosx10.6" and it would work.  Right, Cary?
> 
> I'm happy to make that change (I find that on XCode4 + MountainLion, I can
> simply "unset it", and everything works too), but I don't have a 10.6 machine
to
> see if that would work there.  I could land it and just watch the bots, I
> suppose.

Note also that this change doesn't actually change anything by default, for any
platform.  It just allows you to set it in GYP_DEFINES (or ~/.gyp/include.gypi).

[epoger, 2012-09-20 15:26:09]

http://codereview.appspot.com/6553044/diff/2002/gyp/common_variables.gypi
File gyp/common_variables.gypi (right):

http://codereview.appspot.com/6553044/diff/2002/gyp/common_variables.gypi#new...
gyp/common_variables.gypi:81: 'skia_osx_sdkroot%': 'macos10.6',
I'm pretty sure this is wrong...

its original value was 'macosx10.6'

My suggestion:
1. change this to 'macosx'
2. test it locally on your 10.8 (or 10.7) machine (not overriding
skia_osx_sdkroot)
3. upload new patch
4. I'll patch it in and try it on my 10.6 machine

[Stephen White, 2012-09-20 15:34:04]

On 2012/09/20 15:26:09, epoger wrote:
> http://codereview.appspot.com/6553044/diff/2002/gyp/common_variables.gypi
> File gyp/common_variables.gypi (right):
> 
>
http://codereview.appspot.com/6553044/diff/2002/gyp/common_variables.gypi#new...
> gyp/common_variables.gypi:81: 'skia_osx_sdkroot%': 'macos10.6',
> I'm pretty sure this is wrong...
> 
> its original value was 'macosx10.6'

Whoops!  Good catch, thanks!

> My suggestion:
> 1. change this to 'macosx'
> 2. test it locally on your 10.8 (or 10.7) machine (not overriding
> skia_osx_sdkroot)
> 3. upload new patch
> 4. I'll patch it in and try it on my 10.6 machine

Done.  Seems to work fine on 10.8.

I think this does mean that on all versions of MacOS, we'll be compiling against
the native SDK for that version (ie., 10.6 SDK on 10.6, 10.7 SDK on 10.7, etc). 
Which is different than what Chrome does, where it builds always with the 10.6
SDK (I think -- thakis@, can you confirm?) in order to produce a single binary
that runs on all versions.

The danger there being that we accidentally start using a 10.7 or 10.8 API in
Skia and don't notice it until we try to roll into Chrome.  (Although that would
probably also break the Skia 10.6 buildbots, so I suppose we'd notice it
earlier, so maybe not a problem).

[epoger, 2012-09-20 15:45:39]

> > My suggestion:
> > 1. change this to 'macosx'
> > 2. test it locally on your 10.8 (or 10.7) machine (not overriding
> > skia_osx_sdkroot)
> > 3. upload new patch
> > 4. I'll patch it in and try it on my 10.6 machine
> 
> Done.  Seems to work fine on 10.8.

<sigh> it fails on my 10.6.8 machine with XCode 3.2.4

$ make all
/Users/epoger/src/skia/green/trunk/gyp_skia
Updating projects from gyp files...
rm -f out/Debug || if test -d out/Debug; then echo "run 'make clean' or
otherwise delete out/Debug"; exit 1; fi
xcodebuild -project out/gyp/core.xcodeproj -configuration Debug

=== BUILD NATIVE TARGET core OF PROJECT core WITH CONFIGURATION Debug ===
Check dependencies
error: There is no SDK with the name or path 'macosx'
[BEROR]error: There is no SDK with the name or path 'macosx'
** BUILD FAILED **

make: *** [core] Error 1


Binging "There is no SDK with the name or path 'macosx'" led me to
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=65716 , which indicates that
this is remedied in XCode 3.2.6.

Does someone have a 10.6 machine with XCode 3.2.6+ installed to test it on?

> 
> I think this does mean that on all versions of MacOS, we'll be compiling
against
> the native SDK for that version (ie., 10.6 SDK on 10.6, 10.7 SDK on 10.7,
etc). 
> Which is different than what Chrome does, where it builds always with the 10.6
> SDK (I think -- thakis@, can you confirm?) in order to produce a single binary
> that runs on all versions.
> 
> The danger there being that we accidentally start using a 10.7 or 10.8 API in
> Skia and don't notice it until we try to roll into Chrome.  (Although that
would
> probably also break the Skia 10.6 buildbots, so I suppose we'd notice it
> earlier, so maybe not a problem).

[Stephen White, 2012-09-20 15:53:08]

On 2012/09/20 15:45:39, epoger wrote:
> > > My suggestion:
> > > 1. change this to 'macosx'
> > > 2. test it locally on your 10.8 (or 10.7) machine (not overriding
> > > skia_osx_sdkroot)
> > > 3. upload new patch
> > > 4. I'll patch it in and try it on my 10.6 machine
> > 
> > Done.  Seems to work fine on 10.8.
> 
> <sigh> it fails on my 10.6.8 machine with XCode 3.2.4
> 
> $ make all
> /Users/epoger/src/skia/green/trunk/gyp_skia
> Updating projects from gyp files...
> rm -f out/Debug || if test -d out/Debug; then echo "run 'make clean' or
> otherwise delete out/Debug"; exit 1; fi
> xcodebuild -project out/gyp/core.xcodeproj -configuration Debug
> 
> === BUILD NATIVE TARGET core OF PROJECT core WITH CONFIGURATION Debug ===
> Check dependencies
> error: There is no SDK with the name or path 'macosx'
> [BEROR]error: There is no SDK with the name or path 'macosx'
> ** BUILD FAILED **
> 
> make: *** [core] Error 1
> 
> 
> Binging "There is no SDK with the name or path 'macosx'" led me to
> http://www.ogre3d.org/forums/viewtopic.php?f=2&t=65716 , which indicates that
> this is remedied in XCode 3.2.6.
> 
> Does someone have a 10.6 machine with XCode 3.2.6+ installed to test it on?

I've put the default back to macosx10.6.  This is safe, while letting me
override it locally without changing files in my checkout (which I'm surely
going to commit by accident at some point).

> > 
> > I think this does mean that on all versions of MacOS, we'll be compiling
> against
> > the native SDK for that version (ie., 10.6 SDK on 10.6, 10.7 SDK on 10.7,
> etc). 
> > Which is different than what Chrome does, where it builds always with the
10.6
> > SDK (I think -- thakis@, can you confirm?) in order to produce a single
binary
> > that runs on all versions.
> > 
> > The danger there being that we accidentally start using a 10.7 or 10.8 API
in
> > Skia and don't notice it until we try to roll into Chrome.  (Although that
> would
> > probably also break the Skia 10.6 buildbots, so I suppose we'd notice it
> > earlier, so maybe not a problem).

[epoger, 2012-09-20 15:53:41]

LGTM

[epoger, 2012-09-20 15:53:53]

On 2012/09/20 15:53:41, epoger wrote:
> LGTM

thanks for wading into the muck :-)

[EricB, 2012-09-20 15:54:53]

On 2012/09/20 15:53:53, epoger wrote:
> On 2012/09/20 15:53:41, epoger wrote:
> > LGTM
> 
> thanks for wading into the muck :-)

LGTM as well.

[Stephen White, 2012-09-20 19:47:01]

On 2012/09/20 15:54:53, EricB wrote:
> On 2012/09/20 15:53:53, epoger wrote:
> > On 2012/09/20 15:53:41, epoger wrote:
> > > LGTM
> > 
> > thanks for wading into the muck :-)
> 
> LGTM as well.

Landed as https://code.google.com/p/skia/source/detail?r=5607.  Closing.

[thakis, 2012-09-21 01:49:44]

> Done.  Seems to work fine on 10.8.
> 
> I think this does mean that on all versions of MacOS, we'll be compiling
against
> the native SDK for that version (ie., 10.6 SDK on 10.6, 10.7 SDK on 10.7,
etc). 
> Which is different than what Chrome does, where it builds always with the 10.6
> SDK (I think -- thakis@, can you confirm?) in order to produce a single binary
> that runs on all versions.

Chrome has a variable "mac_sdk" that works like the thing you're adding in the
last patchset. For unofficial builds, it's set to the output of a small python
script that automatically detects the lowest available sdk >= 10.6 (see
https://chromiumcodereview.appspot.com/10824055), so devs usually don't have to
set it manually. It's always set to 10.6 on bots.

> The danger there being that we accidentally start using a 10.7 or 10.8 API in
> Skia and don't notice it until we try to roll into Chrome.  (Although that
would
> probably also break the Skia 10.6 buildbots, so I suppose we'd notice it
> earlier, so maybe not a problem).