GN Mac build work

Work on GYP generation for GN. The hybrid build now works in xcode and ninja.

Write mac tool to output dir in toolchain setup.

BUG=
R=thakis@chromium.org

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

[brettw, 2013-10-28 19:36:10]

My main question was on appending all C/C++/ObjC/ObjC++ flags together. I
thought you told me how to do this properly, but I couldn't find any examples in
GYP and couldn't figure out how to express it in the UI. Any pointers?

[brettw, 2013-10-28 22:06:54]

Now updated with OTHER_CPLUSPLUSFLAGS

[Nico, 2013-10-28 23:05:14]

lgtm

Thoughts on testing?

https://codereview.chromium.org/46683002/diff/330001/tools/gn/gyp_binary_targ...
File tools/gn/gyp_binary_target_writer.cc (right):

https://codereview.chromium.org/46683002/diff/330001/tools/gn/gyp_binary_targ...
tools/gn/gyp_binary_target_writer.cc:364: WriteArrayValues(out_,
flags.cflags_objc);
OTHER_CFLAGS is used for both C and Obj-C flags.

I was worried that the compiler would warn when seeing an Obj-C flag on a .c
compilation, but apparently that's not the case. It'll make the c and cc compile
commands a bit longer than they need to be though.

One way around that would be to map the handful of objc-only flags (-fobjc-arc ,
-fobjc-gc / -fobjc-gc-only, -Wobjc-missing-property-synthesis,
-fobjc-call-cxx-cdtors) to their corresponding explicit xcode_settings entries
(CLANG_ENABLE_OBJC_ARC, GCC_ENABLE_OBJC_GC,
CLANG_WARN_OBJC_MISSING_PROPERTY_SYNTHESIS, GCC_OBJC_CALL_CXX_CDTORS) but I
think it should be fine as-is too.

https://codereview.chromium.org/46683002/diff/330001/tools/gn/gyp_binary_targ...
tools/gn/gyp_binary_target_writer.cc:393: << FilePathToUTF8(clang_pp_path) <<
"',\n";
gyp's ninja generator doesn't use CC and LDPLUSPLUS but instead uses the
make_global_settings block that it uses on other platforms (yes, that's a bit
inconsistent). So you might want to write that too.

https://codereview.chromium.org/46683002/diff/330001/tools/gn/gyp_target_writ...
File tools/gn/gyp_target_writer.cc (right):

https://codereview.chromium.org/46683002/diff/330001/tools/gn/gyp_target_writ...
tools/gn/gyp_target_writer.cc:42: // Global settings for make. This must match
common.gypi :(
Oh, here it is. Maybe add a comment to that other place saying
"make_global_settings is written elsewhere". I'd also say "for ninja" instead of
or in addition to "for make".

You probably want to write this on other platforms that do clang builds too?

https://codereview.chromium.org/46683002/diff/330001/tools/gn/secondary/build...
File tools/gn/secondary/build/toolchain/mac/BUILD.gn (right):

https://codereview.chromium.org/46683002/diff/330001/tools/gn/secondary/build...
tools/gn/secondary/build/toolchain/mac/BUILD.gn:5: # Should only be running on
Windows.
s/Windows/Mac/

[brettw, 2013-10-29 04:53:46]

On 2013/10/28 23:05:14, Nico wrote:
> lgtm
> 
> Thoughts on testing?

I'm planning on doing something like I did for the NingaBinaryTargetWriter where
it just builds some targets manually and expects some text written to a stream.
I don't want to do that quite yet since doing the expectations is a bit annoying
and I have a handful more features to implement.

[brettw, 2013-10-29 23:44:08]

Committed patchset #5 manually as r231669 (presubmit successful).

[Nico, 2013-10-29 23:48:46]

On Mon, Oct 28, 2013 at 9:53 PM, <brettw@chromium.org> wrote:

> On 2013/10/28 23:05:14, Nico wrote:
>
>> lgtm
>>
>
>  Thoughts on testing?
>>
>
> I'm planning on doing something like I did for the NingaBinaryTargetWriter
> where
> it just builds some targets manually and expects some text written to a
> stream.
> I don't want to do that quite yet since doing the expectations is a bit
> annoying
> and I have a handful more features to implement.
>

gyp used golden files like this early on, and they ended up being a pain
since you need to rebase them when you change your output in minor ways,
and since you rebase them all the time you don't notice when they change in
important ways. gyp now instead runs real builds and just checks if the
final build artifacts are sane. This might be a better model for this too:
Have a test runner that builds a few gn files a) with gn / ninja directly
b) with gn -> gyp -> ninja, and then compare both approaches produce
binaries that behave the same way.


>
>
https://codereview.chromium.**org/46683002/<https://codereview.chromium.org/4...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[brettw, 2013-10-29 23:56:22]

I want to have something like the golden thing for the basic stuff, since some
of the order-only dependency stuff is almost impossible to test properly in a
build.

I've been thinking about something like what you suggest for other cases but
haven't gotten around to writing the framework yet.