Allow the mac_sdk_path GYP variable to set the Mac OS X SDK by path

Allow the mac_sdk_path GYP variable to set the Mac OS X SDK by path.

This is useful for cases where Xcode doesn't know about the SDK, possibly
because the SDK is installed outside of Xcode altogether. For example, Xcode
4.4 does not include a copy of the 10.6 SDK, so if you have a copy of the 10.6
SDK present at /SDKs/MacOSX10.6.sdk, you can put this in ~/.gyp/include.gypi:

{
  'variables': {
    'mac_sdk_path': '/SDKs/MacOSX10.6.sdk',
  },
}

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=148680

[Mark Mentovai, 2012-07-26 21:48:27]

For ninja, this depends on https://chromiumcodereview.appspot.com/10821053 .

[Nico, 2012-07-26 22:34:44]

I think I can get chrome trunk building with the 10.7 SDK. Maybe we should just
recommend doing that, instead of tricks like keeping an old 10.6 SDK around?

[Mark Mentovai, 2012-07-26 22:37:35]

At some point we’re going to need to give up on Xcode 3.2 but still be able to
produce official builds. Those will still need the 10.6 SDK.

[Nico, 2012-07-26 22:38:37]

On 2012/07/26 22:37:35, Mark Mentovai wrote:
> At some point we’re going to need to give up on Xcode 3.2 but still be able to
> produce official builds. Those will still need the 10.6 SDK.

Maybe we can use Xcode 4.3 for that? 4.4 is the first to drop the 10.6 SDK.

[Mark Mentovai, 2012-07-26 22:43:22]

4.3’s dead, and anything pre-4.4 has a potential privacy hole that won’t be
patched (although it doesn’t affect us). When we eventually move the bots to a
recent and supported Xcode version, we won’t want something old and unsupported.

What’s wrong with specifying an SDK by path?

[Nico, 2012-07-26 22:48:24]

LGTM

Nothing, just trying to keep this file shorter. This makes sense for bots. For
developers, I think we should get the build going with the 10.7 sdk and let
mac_sdk default to the output of a python script that automatically selects the
oldest sdk found locally (>= 10.6), so that things Just Work for developers.

[Mark Mentovai, 2012-07-26 22:52:41]

There are other things we found in remoting that are deprecated in the 10.6 SDK
and gone in 10.7 that we’re trying to get rid of, but haven’t been successful
yet. CGDisplayBaseAddress is one example. See http://crbug.com/138999.

(Although “developers should be able to use the 10.7 SDK” is what I had in mind
with comment 6 on that bug.)

[Nico, 2012-07-26 22:56:49]

On Thu, Jul 26, 2012 at 3:52 PM,  <mark@chromium.org> wrote:
> There are other things we found in remoting that are deprecated in the 10.6
> SDK and gone in 10.7 that we’re trying to get rid of, but haven’t been
> successful yet.

Ack. All targets build fine with the 10.7 SDK with
http://codereview.chromium.org/10821035/ (which also contains some
unrelated noise). When the carbon plugin CL is in, 'chrome' should
build fine. After that, only this remoting file and tcalloc.c need
patching for 'all' to build, too.

> CGDisplayBaseAddress is one example. See http://crbug.com/138999.
>
> (Although “developers should be able to use the 10.7 SDK” is what I had in
> mind
> with comment 6 on that bug.)
>
> https://chromiumcodereview.appspot.com/10831039/

[Mark Mentovai, 2012-07-26 23:17:34]

Awesome!