Capture initial SCons build of {base,net,googleurl}_unittests on Mac:...

Capture initial SCons build of {base,net,googleurl}_unittests on Mac:
* Initial flags and options that mimick how XCode builds (e.g.
   XCode uses "gcc -x c++" to compile C++, but g++ to link it).
* Load minimal set of SConscript files:  base, googleurl, net,
  skia, testing, third_party.  (breakpad and webkit to come.)
* Correct .cc => .mm file names (multiple places).
* Add base/{platform_thread,platform_test,worker_pool}_mac.mm.
* Remove -Wall when we build Skia, like we do on Linux.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=2097

[sgk, 2008-09-11 18:01:49]

{base,net,googleurl}_unittests build, not all tests pass yet--next iteration.

[Mark Mentovai, 2008-09-11 19:56:26]

LGTM generally, maybe you want to check this in anyway so we can attack some of
these in a different change?  Or maybe you want to get them out of the way now. 
Your call.

http://codereview.chromium.org/2435/diff/1/4
File build/SConscript.main (right):

http://codereview.chromium.org/2435/diff/1/4#newcode1
Line 1: # Copyright 2008, Google Inc.
License boilerplate should be updated.

http://codereview.chromium.org/2435/diff/1/4#newcode387
Line 387: #'webkit',
We can build WebKit on the Mac, is this just commented out for bootstrapping
because the WebKit SCons build on the Mac isn't working yet?

http://codereview.chromium.org/2435/diff/1/4#newcode391
Line 391: # Reproduce XCode's behavior of using gcc even to link C++,
I don't think we should do this.  I appreciate how you're trying to replicate
exactly what Xcode does, but it's not really the right behavior in a lot of
cases.  Xcode in a lot of cases passes compiler flags that are really the
default, or seems to always pass the same thing in a way that seems to override
the default, but it actually has its own heuristics to decide what to pass and
the right thing to do in our case is to just pass nothing at all, or pass
something different.  To wit:

http://codereview.chromium.org/2435/diff/1/4#newcode393
Line 393: CC = '/Developer/usr/bin/gcc-4.0',
We shouldn't do this because Xcode may not be installed in /Developer.  It's OK
for Xcode to do this because it's not hard-coded to /Developer, it knows its own
path.  For our purposes, we should use the compiler provided for command-line
builds.  Normally, this would just be whatever gcc (or cc) and g++ (or c++) is
in the $PATH.  However, for the Mac build, we want to use gcc 4.2, so let's do:

CC = 'gcc-4.2'
CXX = 'g++-4.2'
LINK = $CXX

(The compiler you get when you just say 'gcc' or 'g++' is dependent on whatever
the user has selected with the gcc_select tool, and as of Xcode 3.1 still
defaults to gcc 4.0.)

http://codereview.chromium.org/2435/diff/1/4#newcode398
Line 398: '-x', 'c',
Here, too, we don't need to strictly emulate what Xcode does.  We should leave
this alone.

Note that there's an Objective-C analogue (.m) to C (.c) in the same way as the
Objective-C++ analogue (.mm) to C++ (.cc).  You haven't accounted for that here.
 We should simply feed .m and .c to gcc, and .mm and .cc (and .cpp) to g++.  The
compiler drivers themselves will automatically select the proper language based
on the file's extension in the absence of -x.

http://codereview.chromium.org/2435/diff/1/4#newcode399
Line 399: '-std=c99',
On the other hand, let's keep this.

http://codereview.chromium.org/2435/diff/1/4#newcode405
Line 405: '-x', '${str(SOURCE).endswith(".mm") and "objective-c++" or "c++"}',
Again, drop.

http://codereview.chromium.org/2435/diff/1/4#newcode406
Line 406: '-fvisibility-inlines-hidden',
I need to understand the interaction between CFLAGS, CXXFLAGS, and CCFLAGS.  It
seems like the former's for C only, the middle for both, and the latter for C++
only.

Going on that assumption, I was surprised to find this in the C++-only section,
but it seems that Xcode only enables it for C++ and not C, so OK.

http://codereview.chromium.org/2435/diff/1/4#newcode409
Line 409: '-arch', 'i386',
Leave this out.  Xcode doesn't hard-code this at i386 the way we're using it,
it's always the architecture of the build host.  Leaving it in looks like an
endorsement that the ppc-to-x86 cross build works, but until we can actually
test and support that, I don't think we should have it.  Leaving it out means
that the compiler driver will always build for the build host's architecture, so
our x86 builds will be right, and if someone wants to hack on this stuff on a
ppc, they can.

http://codereview.chromium.org/2435/diff/1/4#newcode410
Line 410: '-fmessage-length=0',
I think we should match whatever Linux does here, as this only affects compiler
stderr output.  Although I personally do like 0, I was never fond of rewrapped
messages in this case.

http://codereview.chromium.org/2435/diff/1/4#newcode411
Line 411: '-pipe',
Again, -pipe is generally good and I think we should spread the goodness to
other gcc users.

http://codereview.chromium.org/2435/diff/1/4#newcode412
Line 412: '-Wno-trigraphs',
I don't know why Xcode puts this in.  -Wall turns -Wtrigraphs back on, so it's
extraneous.

http://codereview.chromium.org/2435/diff/1/4#newcode413
Line 413: '-O0',
Tell me about how we manage release and debug-mode builds with SCons.  This, and
a few other settings, is only appropriate for debug builds.

http://codereview.chromium.org/2435/diff/1/4#newcode428
Line 428: AR = '/Developer/usr/bin/libtool',
Here, too, just 'libtool'.

But libtool's kind of lame.  If you're just going to call it as "libtool -static
blahblahblah", you might as well set AR to 'ar' and use it as you'd expect. 
libtool doesn't do anything special here at all.

http://codereview.chromium.org/2435/diff/1/4#newcode431
Line 431: '-arch_only', 'i386',
Leave this out, per above.

http://codereview.chromium.org/2435/diff/1/4#newcode436
Line 436: '-arch', 'i386',
Leave this out too.

http://codereview.chromium.org/2435/diff/1/4#newcode439
Line 439: env.Dir('${TARGET_ROOT}'),
What's TARGET_ROOT?

http://codereview.chromium.org/2435/diff/1/4#newcode440
Line 440:
'/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks',
I don't think we should hard-code this here, not everything will need this
framework path.

http://codereview.chromium.org/2435/diff/1/4#newcode442
Line 442: FRAMEWORKS = [
And not everything will need these frameworks.

In fact, neither of these frameworks need the above entry for the framework path
set at all.

(p.s. I'd sort them anyway, it's an error that they're not currently sorted in
base.xcodeproj.)

http://codereview.chromium.org/2435/diff/1/2
File net/SConscript (right):

http://codereview.chromium.org/2435/diff/1/2#newcode258
Line 258: '../base/platform_test_mac.o',
Ew, this is icky.  We need to figure something better out here.

[sgk, 2008-09-11 21:57:04]

http://codereview.chromium.org/2435/diff/1/4
File build/SConscript.main (right):

http://codereview.chromium.org/2435/diff/1/4#newcode1
Line 1: # Copyright 2008, Google Inc.
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> License boilerplate should be updated.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode387
Line 387: #'webkit',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> We can build WebKit on the Mac, is this just commented out for bootstrapping
> because the WebKit SCons build on the Mac isn't working yet?

Yes, uncommenting webkit will come in the next change(s) when I get a chance to
tackle Pinkerton's latest work.

http://codereview.chromium.org/2435/diff/1/4#newcode393
Line 393: CC = '/Developer/usr/bin/gcc-4.0',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> We shouldn't do this because Xcode may not be installed in /Developer.  It's
OK
> for Xcode to do this because it's not hard-coded to /Developer, it knows its
own
> path.  For our purposes, we should use the compiler provided for command-line
> builds.  Normally, this would just be whatever gcc (or cc) and g++ (or c++) is
> in the $PATH.  However, for the Mac build, we want to use gcc 4.2, so let's
do:
> 
> CC = 'gcc-4.2'
> CXX = 'g++-4.2'
> LINK = $CXX
> 
> (The compiler you get when you just say 'gcc' or 'g++' is dependent on
whatever
> the user has selected with the gcc_select tool, and as of Xcode 3.1 still
> defaults to gcc 4.0.)

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode398
Line 398: '-x', 'c',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Here, too, we don't need to strictly emulate what Xcode does.  We should leave
> this alone.
> 
> Note that there's an Objective-C analogue (.m) to C (.c) in the same way as
the
> Objective-C++ analogue (.mm) to C++ (.cc).  You haven't accounted for that
here.
>  We should simply feed .m and .c to gcc, and .mm and .cc (and .cpp) to g++. 
The
> compiler drivers themselves will automatically select the proper language
based
> on the file's extension in the absence of -x.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode405
Line 405: '-x', '${str(SOURCE).endswith(".mm") and "objective-c++" or "c++"}',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Again, drop.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode406
Line 406: '-fvisibility-inlines-hidden',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> I need to understand the interaction between CFLAGS, CXXFLAGS, and CCFLAGS. 
It
> seems like the former's for C only, the middle for both, and the latter for
C++
> only.
> 
> Going on that assumption, I was surprised to find this in the C++-only
section,
> but it seems that Xcode only enables it for C++ and not C, so OK.

Yeah, I'm going here from what empirically works.  Specifying
-fvisibility-inlines-hidden for C code actually generated an error (or a warning
with -Werror, I forget which now and don't have that log file anymore).

http://codereview.chromium.org/2435/diff/1/4#newcode409
Line 409: '-arch', 'i386',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Leave this out.  Xcode doesn't hard-code this at i386 the way we're using it,
> it's always the architecture of the build host.  Leaving it in looks like an
> endorsement that the ppc-to-x86 cross build works, but until we can actually
> test and support that, I don't think we should have it.  Leaving it out means
> that the compiler driver will always build for the build host's architecture,
so
> our x86 builds will be right, and if someone wants to hack on this stuff on a
> ppc, they can.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode412
Line 412: '-Wno-trigraphs',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> I don't know why Xcode puts this in.  -Wall turns -Wtrigraphs back on, so it's
> extraneous.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode413
Line 413: '-O0',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Tell me about how we manage release and debug-mode builds with SCons.  This,
and
> a few other settings, is only appropriate for debug builds.

Right now it's just debug build.  Release will be done by copying stripping out
the debug specific portions, leaving the common settings in this environment,
and then we only apply the debug or release flags before kicking off the rest of
the build(s).  That's a TODO for all of the platforms; I'll make a note of this
for the next iteration on mac.

http://codereview.chromium.org/2435/diff/1/4#newcode428
Line 428: AR = '/Developer/usr/bin/libtool',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Here, too, just 'libtool'.
> 
> But libtool's kind of lame.  If you're just going to call it as "libtool
-static
> blahblahblah", you might as well set AR to 'ar' and use it as you'd expect. 
> libtool doesn't do anything special here at all.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode431
Line 431: '-arch_only', 'i386',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Leave this out, per above.

Excellent, getting rid of this plus using 'ar' take us back to using SCons'
default settings, so all of this goes away completely and cleans up things
nicely.

http://codereview.chromium.org/2435/diff/1/4#newcode436
Line 436: '-arch', 'i386',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Leave this out too.

Done.

http://codereview.chromium.org/2435/diff/1/4#newcode439
Line 439: env.Dir('${TARGET_ROOT}'),
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> What's TARGET_ROOT?

The top of the build directory:  "Debug" or "Release" (but it currently defaults
to "Hammer" so I can do side-by-side builds with XCode and compare output).

http://codereview.chromium.org/2435/diff/1/4#newcode440
Line 440:
'/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> I don't think we should hard-code this here, not everything will need this
> framework path.

This is actually in the corresponding command line in the XCode build, and
without this, I get a compile error:

/Users/sgk/src/chrome/trunk/src/base/gfx/rect.cc:10:37: error:
CoreGraphics/CGGeometry.h: No such file or directory

http://codereview.chromium.org/2435/diff/1/4#newcode442
Line 442: FRAMEWORKS = [
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> And not everything will need these frameworks.
> 
> In fact, neither of these frameworks need the above entry for the framework
path
> set at all.
> 
> (p.s. I'd sort them anyway, it's an error that they're not currently sorted in
> base.xcodeproj.)

Cool, will sort.

Sounds like these framework lists really belong with the individual targets. 
I'll move them.

http://codereview.chromium.org/2435/diff/1/2
File net/SConscript (right):

http://codereview.chromium.org/2435/diff/1/2#newcode258
Line 258: '../base/platform_test_mac.o',
On 2008/09/11 19:56:26, Mark Mentovai wrote:
> Ew, this is icky.  We need to figure something better out here.

re: short IRC exchange, I think this could belong somewhere under testing/

[Mark Mentovai, 2008-09-11 22:54:51]

Much cleaner this time.  LG with these bits handled.

(Or do you not want to handle the framework thing yet?)

http://codereview.chromium.org/2435/diff/1/4
File build/SConscript.main (right):

http://codereview.chromium.org/2435/diff/1/4#newcode440
Line 440:
'/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks',
sgk wrote:
> This is actually in the corresponding command line in the XCode build, and
> without this, I get a compile error:

Oh, yeah, forgot about that.  This belongs in base's SConscript, then - but you
already realized that below.

http://codereview.chromium.org/2435/diff/8/209#newcode366
Line 366: '__env__, RDirs, TARGET, SOURCE)}'),
Comment is no longer valid.

[sgk, 2008-09-11 22:58:09]

I'll handle the frameworks thing as a follow-on.  I'm eager to see at least the
build step green in the bot... :-)