Allow an override of MACOSX_DEPLOYMENT_TARGET, so the user can built against a different SDK if des…

Allow an override of MACOSX_DEPLOYMENT_TARGET, so the user can build against a different SDK if desired.

R=mtklein@google.com, bungeman, mtklein

Committed: https://code.google.com/p/skia/source/detail?r=13126

[Stephen White, 2014-01-17 02:30:50]

PTAL

[Stephen White, 2014-01-17 02:35:24]

On 2014/01/17 02:30:50, Stephen White wrote:
> PTAL

(For background, this seems to be a new manifestation of
https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode doesn't
ship with a 10.6 SDK.)

[mtklein, 2014-01-17 14:48:45]

On 2014/01/17 02:35:24, Stephen White wrote:
> On 2014/01/17 02:30:50, Stephen White wrote:
> > PTAL
> 
> (For background, this seems to be a new manifestation of
> https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode doesn't
> ship with a 10.6 SDK.)

Can you send us a failing build log, as verbose as is reasonable?  Are you using
this to push MACOSX_DEPLOYMENT_TARGET forward or backward?

The whole idea of the change was to prevent us from having to worry about this
sort of thing.  As tested on my laptop and the bots, MACOSX_DEPLOYMENT_TARGET
10.6 should work with the default compilers and default SDKs on 10.6, 10.7,
10.8, and 10.9, and the non-default compilers I tried (Clang 3.4, Clang HEAD) on
10.9 worked too.  Should be that even using the very latest SDK, the compiler
will restrict itself to features that are known to be available on >=10.6, or
possibly dynamically test for ones added between SDK 10.6 and that SDK; all the
binaries should work on 10.6.  If this isn't true, I'd like to take a swing at
fixing it before we add a knob.

[Stephen White, 2014-01-17 15:20:14]

On 2014/01/17 14:48:45, mtklein wrote:
> On 2014/01/17 02:35:24, Stephen White wrote:
> > On 2014/01/17 02:30:50, Stephen White wrote:
> > > PTAL
> > 
> > (For background, this seems to be a new manifestation of
> > https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode doesn't
> > ship with a 10.6 SDK.)
> 
> Can you send us a failing build log, as verbose as is reasonable?

[614/937] OBJCXX obj/src/views/mac/views.skia_mac.o
FAILED: g++ -MMD -MF obj/src/views/mac/views.skia_mac.o.d -DSK_GAMMA_SRGB
-DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED
-DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1 -DSK_SUPPORT_OPENCL=0
-DSK_DISTANCEFIELD_FONTS=0 -DSK_SCALAR_IS_FLOAT -DSK_CAN_USE_FLOAT
-DSK_BUILD_FOR_MAC -DSK_USE_POSIX_THREADS -DSK_RELEASE -DNDEBUG
-I../../include/views -I../../include/views/unix -I../../include/gpu
-I../../gyp/config -I../../include/config -I../../include/core
-I../../include/lazy -I../../include/pathops -I../../include/pipe
-I../../gyp/ext -I../../include/utils/mac -I../../include/effects
-I../../include/images -I../../third_party/externals/libjpeg
-I../../include/ports -I../../src/sfnt -I../../include/utils -I../../include/xml
-fasm-blocks -mpascal-strings -O3 -gdwarf-2 -Wnewline-eof
-mmacosx-version-min=10.6 -arch x86_64 -mssse3 -fvisibility=hidden
-fvisibility-inlines-hidden  -c ../../src/views/mac/skia_mac.mm -o
obj/src/views/mac/views.skia_mac.o
In file included from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
                 from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
                 from ../../src/views/mac/skia_mac.mm:9:
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
error: expected `}' before ‘__attribute__’
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
error: expected unqualified-id before ‘=’ token
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:17:
error: expected declaration before ‘}’ token

> Are you using
> this to push MACOSX_DEPLOYMENT_TARGET forward or backward?

Forward, so that I can build against the SDK I have installed.

> The whole idea of the change was to prevent us from having to worry about this
> sort of thing.  As tested on my laptop and the bots, MACOSX_DEPLOYMENT_TARGET
> 10.6 should work with the default compilers and default SDKs on 10.6, 10.7,
> 10.8, and 10.9, and the non-default compilers I tried (Clang 3.4, Clang HEAD)
on
> 10.9 worked too.  Should be that even using the very latest SDK, the compiler
> will restrict itself to features that are known to be available on >=10.6, or
> possibly dynamically test for ones added between SDK 10.6 and that SDK; all
the
> binaries should work on 10.6.  If this isn't true, I'd like to take a swing at
> fixing it before we add a knob.

Note that this was just putting back a knob that was previously available, and
allows me to build.

[mtklein, 2014-01-17 15:39:48]

On 2014/01/17 15:20:14, Stephen White wrote:
> On 2014/01/17 14:48:45, mtklein wrote:
> > On 2014/01/17 02:35:24, Stephen White wrote:
> > > On 2014/01/17 02:30:50, Stephen White wrote:
> > > > PTAL
> > > 
> > > (For background, this seems to be a new manifestation of
> > > https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode
doesn't
> > > ship with a 10.6 SDK.)
> > 
> > Can you send us a failing build log, as verbose as is reasonable?
> 
> [614/937] OBJCXX obj/src/views/mac/views.skia_mac.o
> FAILED: g++ -MMD -MF obj/src/views/mac/views.skia_mac.o.d -DSK_GAMMA_SRGB
> -DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED
> -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1
-DSK_SUPPORT_OPENCL=0
> -DSK_DISTANCEFIELD_FONTS=0 -DSK_SCALAR_IS_FLOAT -DSK_CAN_USE_FLOAT
> -DSK_BUILD_FOR_MAC -DSK_USE_POSIX_THREADS -DSK_RELEASE -DNDEBUG
> -I../../include/views -I../../include/views/unix -I../../include/gpu
> -I../../gyp/config -I../../include/config -I../../include/core
> -I../../include/lazy -I../../include/pathops -I../../include/pipe
> -I../../gyp/ext -I../../include/utils/mac -I../../include/effects
> -I../../include/images -I../../third_party/externals/libjpeg
> -I../../include/ports -I../../src/sfnt -I../../include/utils
-I../../include/xml
> -fasm-blocks -mpascal-strings -O3 -gdwarf-2 -Wnewline-eof
> -mmacosx-version-min=10.6 -arch x86_64 -mssse3 -fvisibility=hidden
> -fvisibility-inlines-hidden  -c ../../src/views/mac/skia_mac.mm -o
> obj/src/views/mac/views.skia_mac.o
> In file included from
> /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
>                  from
> /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
>                  from ../../src/views/mac/skia_mac.mm:9:
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> error: expected `}' before ‘__attribute__’
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> error: expected unqualified-id before ‘=’ token
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:17:
> error: expected declaration before ‘}’ token
> 
> > Are you using
> > this to push MACOSX_DEPLOYMENT_TARGET forward or backward?
> 
> Forward, so that I can build against the SDK I have installed.
> 
> > The whole idea of the change was to prevent us from having to worry about
this
> > sort of thing.  As tested on my laptop and the bots,
MACOSX_DEPLOYMENT_TARGET
> > 10.6 should work with the default compilers and default SDKs on 10.6, 10.7,
> > 10.8, and 10.9, and the non-default compilers I tried (Clang 3.4, Clang
HEAD)
> on
> > 10.9 worked too.  Should be that even using the very latest SDK, the
compiler
> > will restrict itself to features that are known to be available on >=10.6,
or
> > possibly dynamically test for ones added between SDK 10.6 and that SDK; all
> the
> > binaries should work on 10.6.  If this isn't true, I'd like to take a swing
at
> > fixing it before we add a knob.
> 
> Note that this was just putting back a knob that was previously available, and
> allows me to build.

What's your OS, and what's g++ -v?  Is it perhaps llvm-gcc 4.2 (gcc version
4.2.1 (Apple Inc. ...)) on not-10.6?  I can reproduce this now on 10.9 using
homebrew's apple-gcc42 package.  I'll see if I can get this working.

Out of curiosity, do you have clang++ to try?

Please keep in mind this is a different knob.  We're working with x <= y here. 
The knob used to control y, and this new one controls x.  It should be x == 10.6
is <= all y we care about.

[Stephen White, 2014-01-17 16:04:31]

On 2014/01/17 15:39:48, mtklein wrote:
> On 2014/01/17 15:20:14, Stephen White wrote:
> > On 2014/01/17 14:48:45, mtklein wrote:
> > > On 2014/01/17 02:35:24, Stephen White wrote:
> > > > On 2014/01/17 02:30:50, Stephen White wrote:
> > > > > PTAL
> > > > 
> > > > (For background, this seems to be a new manifestation of
> > > > https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode
> doesn't
> > > > ship with a 10.6 SDK.)
> > > 
> > > Can you send us a failing build log, as verbose as is reasonable?
> > 
> > [614/937] OBJCXX obj/src/views/mac/views.skia_mac.o
> > FAILED: g++ -MMD -MF obj/src/views/mac/views.skia_mac.o.d -DSK_GAMMA_SRGB
> > -DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED
> > -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1
> -DSK_SUPPORT_OPENCL=0
> > -DSK_DISTANCEFIELD_FONTS=0 -DSK_SCALAR_IS_FLOAT -DSK_CAN_USE_FLOAT
> > -DSK_BUILD_FOR_MAC -DSK_USE_POSIX_THREADS -DSK_RELEASE -DNDEBUG
> > -I../../include/views -I../../include/views/unix -I../../include/gpu
> > -I../../gyp/config -I../../include/config -I../../include/core
> > -I../../include/lazy -I../../include/pathops -I../../include/pipe
> > -I../../gyp/ext -I../../include/utils/mac -I../../include/effects
> > -I../../include/images -I../../third_party/externals/libjpeg
> > -I../../include/ports -I../../src/sfnt -I../../include/utils
> -I../../include/xml
> > -fasm-blocks -mpascal-strings -O3 -gdwarf-2 -Wnewline-eof
> > -mmacosx-version-min=10.6 -arch x86_64 -mssse3 -fvisibility=hidden
> > -fvisibility-inlines-hidden  -c ../../src/views/mac/skia_mac.mm -o
> > obj/src/views/mac/views.skia_mac.o
> > In file included from
> > /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
> >                  from
> > /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> >                  from ../../src/views/mac/skia_mac.mm:9:
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > error: expected `}' before ‘__attribute__’
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > error: expected unqualified-id before ‘=’ token
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:17:
> > error: expected declaration before ‘}’ token
> > 
> > > Are you using
> > > this to push MACOSX_DEPLOYMENT_TARGET forward or backward?
> > 
> > Forward, so that I can build against the SDK I have installed.
> > 
> > > The whole idea of the change was to prevent us from having to worry about
> this
> > > sort of thing.  As tested on my laptop and the bots,
> MACOSX_DEPLOYMENT_TARGET
> > > 10.6 should work with the default compilers and default SDKs on 10.6,
10.7,
> > > 10.8, and 10.9, and the non-default compilers I tried (Clang 3.4, Clang
> HEAD)
> > on
> > > 10.9 worked too.  Should be that even using the very latest SDK, the
> compiler
> > > will restrict itself to features that are known to be available on >=10.6,
> or
> > > possibly dynamically test for ones added between SDK 10.6 and that SDK;
all
> > the
> > > binaries should work on 10.6.  If this isn't true, I'd like to take a
swing
> at
> > > fixing it before we add a knob.
> > 
> > Note that this was just putting back a knob that was previously available,
and
> > allows me to build.
> 
> What's your OS,

10.9.1

> and what's g++ -v?

i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658)
(LLVM build 2336.11.00)

> Is it perhaps llvm-gcc 4.2 (gcc version
> 4.2.1 (Apple Inc. ...)) on not-10.6?  I can reproduce this now on 10.9 using
> homebrew's apple-gcc42 package.  I'll see if I can get this working.
> 
> Out of curiosity, do you have clang++ to try?
> 
> Please keep in mind this is a different knob.  We're working with x <= y here.

> The knob used to control y, and this new one controls x.  It should be x ==
10.6
> is <= all y we care about.

I'm pretty sure it's because I have XCode 4.6.3, which doesn't include the 10.6
SDK. At least, that was the problem last time (when I updated from XCode 4.2 to
4.4, IIRC).

[mtklein, 2014-01-17 16:58:55]

On 2014/01/17 16:04:31, Stephen White wrote:
> On 2014/01/17 15:39:48, mtklein wrote:
> > On 2014/01/17 15:20:14, Stephen White wrote:
> > > On 2014/01/17 14:48:45, mtklein wrote:
> > > > On 2014/01/17 02:35:24, Stephen White wrote:
> > > > > On 2014/01/17 02:30:50, Stephen White wrote:
> > > > > > PTAL
> > > > > 
> > > > > (For background, this seems to be a new manifestation of
> > > > > https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode
> > doesn't
> > > > > ship with a 10.6 SDK.)
> > > > 
> > > > Can you send us a failing build log, as verbose as is reasonable?
> > > 
> > > [614/937] OBJCXX obj/src/views/mac/views.skia_mac.o
> > > FAILED: g++ -MMD -MF obj/src/views/mac/views.skia_mac.o.d -DSK_GAMMA_SRGB
> > > -DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED
> > > -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1
> > -DSK_SUPPORT_OPENCL=0
> > > -DSK_DISTANCEFIELD_FONTS=0 -DSK_SCALAR_IS_FLOAT -DSK_CAN_USE_FLOAT
> > > -DSK_BUILD_FOR_MAC -DSK_USE_POSIX_THREADS -DSK_RELEASE -DNDEBUG
> > > -I../../include/views -I../../include/views/unix -I../../include/gpu
> > > -I../../gyp/config -I../../include/config -I../../include/core
> > > -I../../include/lazy -I../../include/pathops -I../../include/pipe
> > > -I../../gyp/ext -I../../include/utils/mac -I../../include/effects
> > > -I../../include/images -I../../third_party/externals/libjpeg
> > > -I../../include/ports -I../../src/sfnt -I../../include/utils
> > -I../../include/xml
> > > -fasm-blocks -mpascal-strings -O3 -gdwarf-2 -Wnewline-eof
> > > -mmacosx-version-min=10.6 -arch x86_64 -mssse3 -fvisibility=hidden
> > > -fvisibility-inlines-hidden  -c ../../src/views/mac/skia_mac.mm -o
> > > obj/src/views/mac/views.skia_mac.o
> > > In file included from
> > > /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
> > >                  from
> > > /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> > >                  from ../../src/views/mac/skia_mac.mm:9:
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > > error: expected `}' before ‘__attribute__’
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > > error: expected unqualified-id before ‘=’ token
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:17:
> > > error: expected declaration before ‘}’ token
> > > 
> > > > Are you using
> > > > this to push MACOSX_DEPLOYMENT_TARGET forward or backward?
> > > 
> > > Forward, so that I can build against the SDK I have installed.
> > > 
> > > > The whole idea of the change was to prevent us from having to worry
about
> > this
> > > > sort of thing.  As tested on my laptop and the bots,
> > MACOSX_DEPLOYMENT_TARGET
> > > > 10.6 should work with the default compilers and default SDKs on 10.6,
> 10.7,
> > > > 10.8, and 10.9, and the non-default compilers I tried (Clang 3.4, Clang
> > HEAD)
> > > on
> > > > 10.9 worked too.  Should be that even using the very latest SDK, the
> > compiler
> > > > will restrict itself to features that are known to be available on
>=10.6,
> > or
> > > > possibly dynamically test for ones added between SDK 10.6 and that SDK;
> all
> > > the
> > > > binaries should work on 10.6.  If this isn't true, I'd like to take a
> swing
> > at
> > > > fixing it before we add a knob.
> > > 
> > > Note that this was just putting back a knob that was previously available,
> and
> > > allows me to build.
> > 
> > What's your OS,
> 
> 10.9.1
> 
> > and what's g++ -v?
> 
> i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658)
> (LLVM build 2336.11.00)
> 
> > Is it perhaps llvm-gcc 4.2 (gcc version
> > 4.2.1 (Apple Inc. ...)) on not-10.6?  I can reproduce this now on 10.9 using
> > homebrew's apple-gcc42 package.  I'll see if I can get this working.
> > 
> > Out of curiosity, do you have clang++ to try?
> > 
> > Please keep in mind this is a different knob.  We're working with x <= y
here.
> 
> > The knob used to control y, and this new one controls x.  It should be x ==
> 10.6
> > is <= all y we care about.
> 
> I'm pretty sure it's because I have XCode 4.6.3, which doesn't include the
10.6
> SDK. At least, that was the problem last time (when I updated from XCode 4.2
to
> 4.4, IIRC).

Does 
  CC=clang CXX=clang++ ./gyp_skia && ninja -C out/Debug && echo ok
work for you?

If so I'd recommend switching to clang++.  (That's going to be Clang 3.2 I
think; upgrading to XCode 5 will get you Clang 3.3+ and alias g++ to that.) 
You're going to have a 6 or 7 year better compiler.

If that's not possible, this lgtm.

[Stephen White, 2014-01-20 16:08:43]

On 2014/01/17 16:58:55, mtklein wrote:
> On 2014/01/17 16:04:31, Stephen White wrote:
> > On 2014/01/17 15:39:48, mtklein wrote:
> > > On 2014/01/17 15:20:14, Stephen White wrote:
> > > > On 2014/01/17 14:48:45, mtklein wrote:
> > > > > On 2014/01/17 02:35:24, Stephen White wrote:
> > > > > > On 2014/01/17 02:30:50, Stephen White wrote:
> > > > > > > PTAL
> > > > > > 
> > > > > > (For background, this seems to be a new manifestation of
> > > > > > https://code.google.com/p/skia/issues/detail?id=796, aka newer XCode
> > > doesn't
> > > > > > ship with a 10.6 SDK.)
> > > > > 
> > > > > Can you send us a failing build log, as verbose as is reasonable?
> > > > 
> > > > [614/937] OBJCXX obj/src/views/mac/views.skia_mac.o
> > > > FAILED: g++ -MMD -MF obj/src/views/mac/views.skia_mac.o.d
-DSK_GAMMA_SRGB
> > > > -DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED
> > > > -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1
> > > -DSK_SUPPORT_OPENCL=0
> > > > -DSK_DISTANCEFIELD_FONTS=0 -DSK_SCALAR_IS_FLOAT -DSK_CAN_USE_FLOAT
> > > > -DSK_BUILD_FOR_MAC -DSK_USE_POSIX_THREADS -DSK_RELEASE -DNDEBUG
> > > > -I../../include/views -I../../include/views/unix -I../../include/gpu
> > > > -I../../gyp/config -I../../include/config -I../../include/core
> > > > -I../../include/lazy -I../../include/pathops -I../../include/pipe
> > > > -I../../gyp/ext -I../../include/utils/mac -I../../include/effects
> > > > -I../../include/images -I../../third_party/externals/libjpeg
> > > > -I../../include/ports -I../../src/sfnt -I../../include/utils
> > > -I../../include/xml
> > > > -fasm-blocks -mpascal-strings -O3 -gdwarf-2 -Wnewline-eof
> > > > -mmacosx-version-min=10.6 -arch x86_64 -mssse3 -fvisibility=hidden
> > > > -fvisibility-inlines-hidden  -c ../../src/views/mac/skia_mac.mm -o
> > > > obj/src/views/mac/views.skia_mac.o
> > > > In file included from
> > > >
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
> > > >                  from
> > > > /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> > > >                  from ../../src/views/mac/skia_mac.mm:9:
> > > >
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > > > error: expected `}' before ‘__attribute__’
> > > >
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
> > > > error: expected unqualified-id before ‘=’ token
> > > >
> > >
> >
>
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:17:
> > > > error: expected declaration before ‘}’ token
> > > > 
> > > > > Are you using
> > > > > this to push MACOSX_DEPLOYMENT_TARGET forward or backward?
> > > > 
> > > > Forward, so that I can build against the SDK I have installed.
> > > > 
> > > > > The whole idea of the change was to prevent us from having to worry
> about
> > > this
> > > > > sort of thing.  As tested on my laptop and the bots,
> > > MACOSX_DEPLOYMENT_TARGET
> > > > > 10.6 should work with the default compilers and default SDKs on 10.6,
> > 10.7,
> > > > > 10.8, and 10.9, and the non-default compilers I tried (Clang 3.4,
Clang
> > > HEAD)
> > > > on
> > > > > 10.9 worked too.  Should be that even using the very latest SDK, the
> > > compiler
> > > > > will restrict itself to features that are known to be available on
> >=10.6,
> > > or
> > > > > possibly dynamically test for ones added between SDK 10.6 and that
SDK;
> > all
> > > > the
> > > > > binaries should work on 10.6.  If this isn't true, I'd like to take a
> > swing
> > > at
> > > > > fixing it before we add a knob.
> > > > 
> > > > Note that this was just putting back a knob that was previously
available,
> > and
> > > > allows me to build.
> > > 
> > > What's your OS,
> > 
> > 10.9.1
> > 
> > > and what's g++ -v?
> > 
> > i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
5658)
> > (LLVM build 2336.11.00)
> > 
> > > Is it perhaps llvm-gcc 4.2 (gcc version
> > > 4.2.1 (Apple Inc. ...)) on not-10.6?  I can reproduce this now on 10.9
using
> > > homebrew's apple-gcc42 package.  I'll see if I can get this working.
> > > 
> > > Out of curiosity, do you have clang++ to try?
> > > 
> > > Please keep in mind this is a different knob.  We're working with x <= y
> here.
> > 
> > > The knob used to control y, and this new one controls x.  It should be x
==
> > 10.6
> > > is <= all y we care about.
> > 
> > I'm pretty sure it's because I have XCode 4.6.3, which doesn't include the
> 10.6
> > SDK. At least, that was the problem last time (when I updated from XCode 4.2
> to
> > 4.4, IIRC).
> 
> Does 
>   CC=clang CXX=clang++ ./gyp_skia && ninja -C out/Debug && echo ok
> work for you?
> 
> If so I'd recommend switching to clang++.  (That's going to be Clang 3.2 I
> think; upgrading to XCode 5 will get you Clang 3.3+ and alias g++ to that.) 
> You're going to have a 6 or 7 year better compiler.
> 
> If that's not possible, this lgtm.

Nope, doesn't work. The problem is not the compiler; it's the SDK. Xcode 4.6
comes with the 10.8 and 10.9 SDKs:

ls -l
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 0
drwxr-xr-x  5 root  wheel  170 Sep  5 01:19 MacOSX10.8.sdk
drwxr-xr-x  5 root  wheel  170 Sep 26 03:51 MacOSX10.9.sdk

I suspect this works for you because you've got an older XCode. Unfortunately, I
need a newer version to use the hidpi simulator.

(BTW, the fact that we build Chrome against 10.6 is kind of Chrome-specific;
IIRC we used to build Skia against the native SDK on the bots, so the 10.6 bot
builds against 10.6, 10.7 builds against 10.7, etc. I think this is more robust,
because it means that developers can download skia standalone and be sure that
it will compile against whichever XCode they have installed.)

[Stephen White, 2014-01-20 16:14:08]

Committed patchset #1 manually as r13126 (presubmit successful).

[mtklein, 2014-01-20 23:03:09]

On 2014/01/20 16:14:08, Stephen White wrote:
> Committed patchset #1 manually as r13126 (presubmit successful).

Hey, I think you've got an old mental model here.  I am on a machine that
started with XCode 4.6 and upgraded to 5, and it too has only ever had the 10.8
and 10.9 SDKs.  By changing MACOSX_DEPLOYMENT_TARGET, you are not changing which
SDK you're using (this is what SDKROOT does).  MACOSX_DEPLOYMENT_TARGET changes
the minimum feature set that's considered unconditionally available when
compiling against whatever SDK you've chosen.  We've _stopped_ choosing the SDK,
so you now pick up the default, newest SDK, which for you and me both is 10.9.

You're right that the problem is not the compiler per se, but neither is it the
SDK.  It's the combination of an old compiler and a new SDK.  Apple tags new
features in the SDK with an NS_AVAILABLE macro, which expands either into some
__attribute__ to tell the compiler when it's become available so it can generate
code for a runtime guard, or into a no-op empty macro if the minimum deployment
target (MACOSX_DEPLOYMENT_TARGET) is >= the version given.  In the 10.9 SDK,
Apple added a new value to the NsUserNotificationActivationType enum, and tagged
that new value as available since 10.9 with NS_AVAILABLE.  Now, your g++ is
LLVM-GCC, an old hybrid compiler using GCC's frontend and LLVM as a code
generation backend.  The last version Apple ever released is the one you've got,
which uses GCC 4.2 as a frontend.  That GCC doesn't seem to understand
__attribute__ on enum values, and is barfing when it hits that NS_AVAILABLE
macro on NsUserNotificationActivationType.

Side note: Apple mostly gets away with this because as of XCode 5 they've
stopped shipping LLVM-GCC altogether.  They've even started using non-standard
features (blocks, sort of proto-lambdas with a different syntax) in the SDK API,
which means even the very latest GCC will probably never work completely, though
it can compile non-Cocoa-dependent Skia just fine.  The future on Mac is Clang
or bust, it seems.

Anyway, we can fix the build in at least three ways:
  1) target a minimum of 10.9 instead of 10.6, so that NS_AVAILABLE expands into
a no-op instead of an __attribute__.  This is what you've just added support
for.
  2) roll back time, dropping down from the 10.9 SDK to the 10.8 SDK, where the
new enum value tagged with NS_AVAILABLE didn't exist yet.  This is what our GYP
files used to do for you by setting SDKROOT to the oldest SDK it could find that
was >=10.6.
  3) switch to a newer compiler (set CC=clang CXX=clang++ or upgrade to XCode 5)
that does understand __attribute__ on enum values.

I'm not saying any of 1, 2 or 3 up there is absolutely wrong or right, though 2
does just push the problem off to future-us to solve whenever Apple stops
shipping the 10.8 SDK.  Personally, I think you're going to be happier long term
getting off the zombie llvm-gcc.  Clang will be faster, generate better code,
give you better error messages, supports C++11/14 as that becomes relevant, and,
importantly, is still developed.

Now that I'm thinking about it, there may just be a better fourth way to fix
this, which I think is what you were getting at at the end there: don't set
either SDKROOT or MACOSX_DEPLOYMENT_TARGET.  Each machine should just build
using its own default SDK targeting its own default platform, and we'll rely on
10.{6,7,8} bots to catch any unchecked new feature we might stray into using.  I
bet that'd never even happen: it's pretty rare that we write code for Mac
specifically, and even then I bet it's rare enough to just say never that we'd
blindly attempt to use a 10.7+ feature.

Once again, just so we're clear, things work differently now than they used to. 
Two weeks ago every bot built against the oldest SDK it had available that was
at least as new as 10.6.  Today every bot is building against its native SDK and
is restricting the features it uses unconditionally from that SDK to those
features available on 10.6.  I think we're both proposing that Tomorrow every
bot just builds against its native SDK.  Sound right?

[Stephen White, 2014-01-21 01:21:58]

On 2014/01/20 23:03:09, mtklein wrote:
> On 2014/01/20 16:14:08, Stephen White wrote:
> > Committed patchset #1 manually as r13126 (presubmit successful).
> 
> Hey, I think you've got an old mental model here.  I am on a machine that
> started with XCode 4.6 and upgraded to 5, and it too has only ever had the
10.8
> and 10.9 SDKs.  By changing MACOSX_DEPLOYMENT_TARGET, you are not changing
which
> SDK you're using (this is what SDKROOT does).  MACOSX_DEPLOYMENT_TARGET
changes
> the minimum feature set that's considered unconditionally available when
> compiling against whatever SDK you've chosen.  We've _stopped_ choosing the
SDK,
> so you now pick up the default, newest SDK, which for you and me both is 10.9.

You're right that I was also misdiagnosing the problem. i'm not sure why your
solution didn't work for me, though.

> You're right that the problem is not the compiler per se, but neither is it
the
> SDK.  It's the combination of an old compiler and a new SDK.  Apple tags new
> features in the SDK with an NS_AVAILABLE macro, which expands either into some
> __attribute__ to tell the compiler when it's become available so it can
generate
> code for a runtime guard, or into a no-op empty macro if the minimum
deployment
> target (MACOSX_DEPLOYMENT_TARGET) is >= the version given.  In the 10.9 SDK,
> Apple added a new value to the NsUserNotificationActivationType enum, and
tagged
> that new value as available since 10.9 with NS_AVAILABLE.  Now, your g++ is
> LLVM-GCC, an old hybrid compiler using GCC's frontend and LLVM as a code
> generation backend.  The last version Apple ever released is the one you've
got,
> which uses GCC 4.2 as a frontend.  That GCC doesn't seem to understand
> __attribute__ on enum values, and is barfing when it hits that NS_AVAILABLE
> macro on NsUserNotificationActivationType.

Strange. I was still getting errors on my Mac Pro with CC and CXX set to clang
without MACOSX_DEPLOYMENT_TARGET to 10.9, although it was failing in a different
way than my MBP. It was missing basic POSIX C headers. For some reason, setting
MACOSX_DEPLOYMENT_TARGET fixed it.

I don't really care what the preferred setup is, but it would be nice if Skia
compiled out-of-the-box on any install of XCode, without needing to set
anything.
Failing that, we should document what needs to be set on the Sites page (note
that it still refers to the now-defunct skia_osx_sdkroot).

> Side note: Apple mostly gets away with this because as of XCode 5 they've
> stopped shipping LLVM-GCC altogether.  They've even started using non-standard
> features (blocks, sort of proto-lambdas with a different syntax) in the SDK
API,
> which means even the very latest GCC will probably never work completely,
though
> it can compile non-Cocoa-dependent Skia just fine.  The future on Mac is Clang
> or bust, it seems.

Fine by me, as long as we either:

1) make it work seamlessly, or 
2) document the seams.

> Anyway, we can fix the build in at least three ways:
>   1) target a minimum of 10.9 instead of 10.6, so that NS_AVAILABLE expands
into
> a no-op instead of an __attribute__.  This is what you've just added support
> for.
>   2) roll back time, dropping down from the 10.9 SDK to the 10.8 SDK, where
the
> new enum value tagged with NS_AVAILABLE didn't exist yet.  This is what our
GYP
> files used to do for you by setting SDKROOT to the oldest SDK it could find
that
> was >=10.6.
>   3) switch to a newer compiler (set CC=clang CXX=clang++ or upgrade to XCode
5)
> that does understand __attribute__ on enum values.
> 
> I'm not saying any of 1, 2 or 3 up there is absolutely wrong or right, though
2
> does just push the problem off to future-us to solve whenever Apple stops
> shipping the 10.8 SDK.  Personally, I think you're going to be happier long
term
> getting off the zombie llvm-gcc.  Clang will be faster, generate better code,
> give you better error messages, supports C++11/14 as that becomes relevant,
and,
> importantly, is still developed.

(BTW, I do know what clang are LLVM are (i've even contributed a patch or two to
LLVM); I just didn't bother to set it up on my Mac.)

> Now that I'm thinking about it, there may just be a better fourth way to fix
> this, which I think is what you were getting at at the end there: don't set
> either SDKROOT or MACOSX_DEPLOYMENT_TARGET.  Each machine should just build
> using its own default SDK targeting its own default platform, and we'll rely
on
> 10.{6,7,8} bots to catch any unchecked new feature we might stray into using. 
I
> bet that'd never even happen: it's pretty rare that we write code for Mac
> specifically, and even then I bet it's rare enough to just say never that we'd
> blindly attempt to use a 10.7+ feature.

Yeah, that's what I was getting at. Low-friction for new developers.

> Once again, just so we're clear, things work differently now than they used
to. 
> Two weeks ago every bot built against the oldest SDK it had available that was
> at least as new as 10.6.  Today every bot is building against its native SDK
and
> is restricting the features it uses unconditionally from that SDK to those
> features available on 10.6.  I think we're both proposing that Tomorrow every
> bot just builds against its native SDK.  Sound right?

SGTM. Note that thakis@ knows all this stuff much better than me, and would be a
good person to bounce this off of before you change it.

[Nico, 2014-01-21 02:41:10]

I haven't read the discussion on this review, but the CL description doesn't
make sense: MACOSX_DEPLOYMENT_TARGET isn't what picks the sdk, SDKROOT is. You
can use SDKROOT = 'macosx10.7' to use the 10.7 sdk and still set
MACOSX_DEPLOYMENT_TARGET to 10.6 to target 10.6 and up.


Reading just senorblanco's last comment: Look for "find_sdk.py" in
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
(the script itself is here:
https://code.google.com/p/chromium/codesearch#chromium/src/build/mac/find_sdk...
) to see how we solve this in Chromium.

[Stephen White, 2014-01-21 03:21:18]

On 2014/01/21 02:41:10, Nico wrote:
> I haven't read the discussion on this review, but the CL description doesn't
> make sense: MACOSX_DEPLOYMENT_TARGET isn't what picks the sdk, SDKROOT is. You
> can use SDKROOT = 'macosx10.7' to use the 10.7 sdk and still set
> MACOSX_DEPLOYMENT_TARGET to 10.6 to target 10.6 and up.

Yeah; my CL description is wrong.

I think Mike's right in that the problem is that the 10.9 SDK won't even
properly build with MACOSX_DEPLOYMENT_TARGET set to 10.6 with gcc-llvm, and now
clang is a prerequisite (perhaps not intentional on Apple's part, but they may
not care anymore). Not sure why that didn't work on my Mac Pro, though. Anyway,
for Skia we could:

1) autodetect 10.9, and use clang automatically (so we don't hit this bug)
2) autodetect clang, and use it automatically
3) don't set anything, and let each OS build with its own SDK

I think #3 works in the sense that Skia is a client library that's supposed to
build in many configurations. The 10.6 bots will prevent us from using a
10.7-or-higher API, so we won't roll anything breaking into Chrome.

> Reading just senorblanco's last comment: Look for "find_sdk.py" in
>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
> (the script itself is here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/build/mac/find_sdk...
> ) to see how we solve this in Chromium.