Disclaimer: I'm mostly familiar with iOS, so my answer is only pertaining to iOS.

I implemented the "target_subarch" in gyp and in retrospect, I think it was a mistake. It meant that we lost assembly language optimisation in some libraries (as the decision to use optimised version was made at gyp generation time).

Moreover, given that all new iOS devices are arm64 devices, my plan was to not support fat builds in GN, but instead change how bots builds official builds (that are the only builds that really need to be fat, as developers generally only build for a single architecture, and re-run gyp when they need to use the other) by building in out/xxx-armv7 and out/xxx-arm64 and then gluing the outputs together with lipo (which is basically just what happens with gyp already, except automated).

With GN's toolchain support, it's easy to do a armv7 and arm64 build and glue them together in one GN run.

The remoting pref pane loads into System Settings on OS X. This used to be 32-bit, but now that we've dropped support for 10.6-10.8, I _think_ System Settings is 64-bit on all OS X versions that we support...yup, erikchen kindly just confirmed that.

So I think we don't currently need fat binaries for OS X builds.

(We already landed a patch to no longer let the remoting prefpane build in 32-bit a while ago -- I thought a bit prematurely, but now it's fine to rely on this.)

After https://codereview.chromium.org/1547533002 the CRD pref panel is 64-bit only, so we no longer need fat binaries there.

Cool, it sounds like we can pretty conclusively skip this on Mac, and hopefully
get away with separate merge actions on iOS (and possibly also Android) and
thus not need to bake anything into core GN there, either.

That said, I'll probably leave this open but lower the priority until we get
closer to being done w/ iOS just in case.

(this removes this bug from the mac/gn blocker list. maybe that can be done for ios too.)

For Android WebView what we ideally want is a way to build all the native parts separately for each architecture (not as any kind of "fat" build step, because one thing that would be useful is being able to actually build a *different* binary for 32-bit and 64-bit, since we don't actually need all of the same code in both cases always), but then build all the java code, resources, etc just once, and package them into the APK together without having to merge two fully built APKs later. The current merging approach duplicates building all the non-native parts and requires some fiddling to correctly merge the APKs together.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3bdd5635f4dba38c3035fe992039a833988e147b

commit 3bdd5635f4dba38c3035fe992039a833988e147b
Author: sdefresne <sdefresne@chromium.org>
Date: Sat Mar 26 00:06:26 2016

[iOS/GN] Fix compilation of ios_chrome_unittests with gn.

Get GN in sync with gyp by adding missing dependencies, removing
the obsoletes dependencies and adding missing files and targets.

Change the toolchain when targetting iOS devices to not build fat
binaries as this break the "gn gen"-time selection of the level of
optimisation to use from skia and libwebp. Instead, building for
devices on iOS is now similar to other platforms (i.e. the arch is
selected via "target_cpu" with "arm" an alias for "armv7").

Fixes the following errors:
  Undefined symbols for architecture arm64:
    "_VP8DspInitNEON", referenced from:
        _VP8DspInit in dec.o
  ...

BUG= 459705 , 596237 

Review URL: https://codereview.chromium.org/1810423002

Cr-Commit-Position: refs/heads/master@{#383416}

[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/build/config/arm.gni
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/build/config/mac/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/build/toolchain/mac/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/components/autofill/ios/browser/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/components/dom_distiller/ios/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/components/policy/core/browser/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/ios/chrome/browser/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/ios/chrome/test/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/ios/net/BUILD.gn
[modify] https://crrev.com/3bdd5635f4dba38c3035fe992039a833988e147b/ios/public/provider/chrome/browser/BUILD.gn

I think we've figured out what to do here; we need to file separate tracking bugs for getting the Android and iOS builds updated for this, I think, and then can call it a day.

The iOS bug is  bug 603180 . Android is done.

So, I think we can close this.