GN build fixes, mostly for Mac.

GN build fixes, mostly for Mac.

This hooks up detection for the "-arch" flag on Mac to set the GYP "ARCH" xcode variable. GN then removes the -arch argument from the compiler args, since GYP will then re-add it based on the ARCH value. Previously, not doing this resulting in mutliple "-arch" arguments to the compiler since GYP would always insert its own.

Disables some warnings on Windows for the re2 target to match the GYP build. The third warning (4018) that the GYP build sets is disabled globally so there's no need to do it for this target.

Hooks up some iOS SDK stuff.
BUG=336667
TBR=thakis@chromium.org

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

[brettw, 2014-01-27 06:52:37]

iOS stuff is mostly a stab in the dark but it seems to work on my computer. I
need to figure out all the variants that we build and test those, as well as
check for other flags I've gotten wrong.

[brettw, 2014-01-27 07:40:33]

I'm TBRing this since it requires a binary push to get started on the next level
of stuff.

[brettw, 2014-01-27 07:41:39]

Committed patchset #4 manually as r247206 (presubmit successful).

[Nico, 2014-01-27 19:42:26]

What do you think about starting with system tests before doing changes like
this first? Have a single test with a single hardcoded gyp and gn file
containing a single executable target with a single source file, build both gyp
file using gyp/ninja (and maybe gyp/xcode for ios) and gn file using gn's
gn->gyp->executable logic, compare produced executables for being identical
would've been enough to find the majority of the issues the rollout found.

https://codereview.chromium.org/141433015/diff/80001/build/config/BUILDCONFIG.gn
File build/config/BUILDCONFIG.gn (right):

https://codereview.chromium.org/141433015/diff/80001/build/config/BUILDCONFIG...
build/config/BUILDCONFIG.gn:166: # (which is always true when using GN).
This isn't correct: gn will generate a re2.gyp file which will then be used with
the xcode generator on the regular ios bots (which still use xcode).

https://codereview.chromium.org/141433015/diff/80001/build/config/clang/BUILD.gn
File build/config/clang/BUILD.gn (right):

https://codereview.chromium.org/141433015/diff/80001/build/config/clang/BUILD...
build/config/clang/BUILD.gn:18: if (is_mac || is_ios) {
Same comment here.

The clang / plugin stuff needs to be in a <(GENERATOR)==ninja block on ios (set
some ios_cflags define in that conditional, add that to the regular flags)

https://codereview.chromium.org/141433015/diff/80001/build/config/compiler/BU...
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/141433015/diff/80001/build/config/compiler/BU...
build/config/compiler/BUILD.gn:70: cflags += [ "-mios-simulator-version-min=6.0"
]
I'm not sure if this is good enough: While the ios ninja build currently only
supports simulator builds, the xcode build supports real device builds too – so
setting the simulator flag there won't be correct.

[brettw, 2014-01-28 02:13:41]

https://codereview.chromium.org/141433015/diff/80001/build/config/clang/BUILD.gn
File build/config/clang/BUILD.gn (right):

https://codereview.chromium.org/141433015/diff/80001/build/config/clang/BUILD...
build/config/clang/BUILD.gn:18: if (is_mac || is_ios) {
Yeah, I'm still trying to figure out what to do about this. I'm hoping to hack
some special cases into my GYP generator, but may end up needing to parameterize
the entire build on the GYP generator and writing out all the flags and such
twice in the resulting GYP file.

[brettw, 2014-01-28 02:22:29]

On 2014/01/27 19:42:26, Nico wrote:
> What do you think about starting with system tests before doing changes like
> this first? Have a single test with a single hardcoded gyp and gn file
> containing a single executable target with a single source file, build both
gyp
> file using gyp/ninja (and maybe gyp/xcode for ios) and gn file using gn's
> gn->gyp->executable logic, compare produced executables for being identical
> would've been enough to find the majority of the issues the rollout found.

Really? I actually think it would have found none of them. The problem wasn't
that there were flags subtly wrong in ways that are difficult to detect, but
that I didn't know (and still don't) the scope of things to test and what flags
people use. Like setting hardfp, -G output directories, mismatched
make_global_settings due to differences in goma, etc. I don't even think doing
what you describe would have found the multiple different -arch definition on
Mac, since I don't think it can do both, and I don't think it would have linked
at all if it had picked the "wrong one" (it linked on my configuration).

[Nico, 2014-01-28 03:34:19]

On Mon, Jan 27, 2014 at 6:22 PM, <brettw@chromium.org> wrote:

> On 2014/01/27 19:42:26, Nico wrote:
>
>> What do you think about starting with system tests before doing changes
>> like
>> this first? Have a single test with a single hardcoded gyp and gn file
>> containing a single executable target with a single source file, build
>> both
>>
> gyp
>
>> file using gyp/ninja (and maybe gyp/xcode for ios) and gn file using gn's
>> gn->gyp->executable logic, compare produced executables for being
>> identical
>> would've been enough to find the majority of the issues the rollout found.
>>
>
> Really? I actually think it would have found none of them.


It would've found:
* NDEBUG not being defined
* Different -O flags
* I think the -arch flags (since re would've ended up with a fat binary and
gyp wouldn't)
* least some of the ios issues

I agree it wouldn't have found the goma issues. (I've converted the android
bots to use is_goma like devs do and have a CL in-flight to do this for the
non-android bots, so is_goma should be covered by bots by now.)


> The problem wasn't
> that there were flags subtly wrong in ways that are difficult to detect,
> but
> that I didn't know (and still don't) the scope of things to test and what
> flags
> people use. Like setting hardfp, -G output directories, mismatched
> make_global_settings due to differences in goma, etc. I don't even think
> doing
> what you describe would have found the multiple different -arch definition
> on
> Mac, since I don't think it can do both, and I don't think it would have
> linked
> at all if it had picked the "wrong one" (it linked on my configuration).
>
> https://codereview.chromium.org/141433015/
>

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